[Bf-usd] Support for Preliminary_Text (Link to Apple's documentation)

[Thomas Kumlehn]

Here’s the official developer page
https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text <https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text>
But again, on June 6th we should expect major updates.


Thomas Kumlehn
pixelpartner at icloud.com



> Am 25.04.2022 um 12:00 schrieb bf-usd-request at blender.org:
> 
> Send Bf-usd mailing list submissions to
> 	bf-usd at blender.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.blender.org/mailman/listinfo/bf-usd
> or, via email, send a message with subject or body 'help' to
> 	bf-usd-request at blender.org
> 
> You can reach the person managing the list at
> 	bf-usd-owner at blender.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-usd digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Support for Preliminary_Text (Sybren A. Stüvel)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 25 Apr 2022 11:47:02 +0200
> From: Sybren A. Stüvel <sybren at blender.org>
> To: Blender USD Workgroup <bf-usd at blender.org>
> Subject: Re: [Bf-usd] Support for Preliminary_Text
> Message-ID:
> 	<CAFOOXSbbbGR30d16NHdzVPXSsym_DZp+G=xiB2uEaUx-atW7eg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> On Thu, 21 Apr 2022 at 18:45, John Harrison via Bf-usd <bf-usd at blender.org>
> wrote:
> 
>> Implementing an importer as part of the same effort makes sense to me
>> (more work of course) because it balances the feature set and will help
>> with testing (import->export & compare). [...] Regarding font point size, I
>> would use Reality Composer as “ground truth” and see how it maps font point
>> sizes to designer units (meters usually), then document my findings and
>> follow suite.
>> 
> 
> Public specifications are always better. If there is no other way, we can
> try and follow what some proprietary application is doing, but that opens
> the door to all kinds of nasty issues. The most important aspect is that
> triagers and Blender developers won't be able to reproduce bug reports.
> Being able to go through an export-import cycle and see that the result is
> the same is a good start, but that's not enough to ensure the
> implementation is correct.
> 
> We have been in this situation with Alembic, where different applications
> had different interpretations of certain data, and Blender was stuck in the
> middle. I don't want to repeat this process with USD. Especially when
> implementing support for a 3rd party extension, I feel that we have to be
> careful and have a thorough understanding of that extension before writing
> any code.
> 
> Sybren
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20220425/4647ca55/attachment-0001.htm>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> Bf-usd mailing list
> Bf-usd at blender.org
> https://lists.blender.org/mailman/listinfo/bf-usd
> 
> 
> ------------------------------
> 
> End of Bf-usd Digest, Vol 15, Issue 4
> *************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20220425/699b2aac/attachment-0001.htm>