[Bf-usd] Support for Preliminary_Text

[John Harrison]

Hi everyone~

I like “official” but I’m not sure the best way to achieve this. Apple does have some documentation publicly available, but it is not detailed enough. Also, as someone previously mentioned, it is preliminary and therefore likely to change without us knowing. I agree that code should follow design.

It seems like a well-described RFC would be the ideal case here, as it is for many standard formats. I would prefer to not invent a parallel specification if such an RFC-like document is in the works and to-be released soon by Apple/Pixar. Anyone have an Apple/Pixar contact that can share more information about the state and intended future of these preliminary defs?

Best,
John

> On Apr 25, 2022, at 6:47 AM, Sybren A. Stüvel via Bf-usd <bf-usd at blender.org> wrote:
> 
> 
> Hello all,
> 
> Ton and I had a little chat about this. We both feel that the best path to walk is to have an official way to encode text in USD. This could then also have an Open Source official reference implementation, for example in Hydra or perhaps even Blender. This "official way" could be as some extension to USD, but at least it should be officially approved & documented unambiguously. Of course kerning and other "details" of font rendering should be taken into account, such that every application that opens the USD file produces the same result.
> 
> Sybren
> 
> 
>> On Mon, 25 Apr 2022 at 12:12, Bastien Montagne via Bf-usd <bf-usd at blender.org> wrote:
>> Hi,
>> 
>> Having to suffer the FBX (in)famous case, I fully support Sybren's point here. I would also strongly advocate against working with any standard or extension of a standard which specifications are not publicly available. This is road to Hell and never-ending maintenance.
>> 
>> Cheers,
>> Bastien
>> 
>> On 4/25/22 11:47, Sybren A. Stüvel via Bf-usd wrote:
>>> 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
>>> 
>>> 
>>> _______________________________________________
>>> Bf-usd mailing list
>>> Bf-usd at blender.org
>>> List details, subscription details or unsubscribe:
>>> https://lists.blender.org/mailman/listinfo/bf-usd
>> -- 
>> ----------------
>> Bastien Montagne
>> Blender Developer
>> _______________________________________________
>> Bf-usd mailing list
>> Bf-usd at blender.org
>> List details, subscription details or unsubscribe:
>> https://lists.blender.org/mailman/listinfo/bf-usd
> _______________________________________________
> Bf-usd mailing list
> Bf-usd at blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-usd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20220425/487c7830/attachment.htm>