[Bf-usd] Support for Preliminary_Text

[Sybren A. Stüvel]

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 listBf-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20220425/a7b19d16/attachment.htm>