<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Apr 2022 at 18:45, John Harrison via Bf-usd <<a href="mailto:bf-usd@blender.org">bf-usd@blender.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>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.</div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div> </div><div>Sybren<br></div></div></div>