<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Sybren and others~<div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">Regarding how to implement an importer and exporter, I will need some direction to get started, but would be surprised if it didn’t involve coding.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Regarding width/height, I’ll lean on others here. It makes sense IFF the runtime renders exactly the same as the designer (Blender), but what if the runtime doesn’t have the font family, or the font style (bold, italic)? I cannot vouch for a different runtime honoring the text attributes 100%, which is why I am hesitant about these two fields. Regarding their value, it is nice to know up front how much space the text will use.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">John</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 21, 2022, at 5:53 AM, Sybren A. Stüvel <<a href="mailto:sybren@blender.org" class="">sybren@blender.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">Hi John & fellow USD list members,<br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Apr 2022 at 13:51, John Harrison via Bf-usd <<a href="mailto:bf-usd@blender.org" class="">bf-usd@blender.org</a>> wrote:<br class=""></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;" class="">Hi,
 I’m a software developer (never contributed to blender) motivated 
(possibly?) to implement USD export support for one of Apple’s schema 
additions, namely Preliminary_Text: <a href="https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text" target="_blank" class="">https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text</a></div></blockquote><div class=""><br class=""></div><div class="">That looks like a nice addition to me. Would you also be able to implement the importer side of this?<br class=""></div><div class=""><br class=""></div><div class="">Personally I don't have any experience with extending the standard USD schema. How would this work on a technical level? Would it require Blender to bundle any additional schema files? Would the mere existence of such schema files be enough, or would Blender's USD handling code also have to change?<br class=""></div><div class=""> </div></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Apr 2022 at 19:26, John Harrison via Bf-usd <<a href="mailto:bf-usd@blender.org" class="">bf-usd@blender.org</a>> wrote:<br class=""></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;" class="">Great questions Charles, here are my thoughts in the same order as your questions (learning as I go here):<div class=""><br class=""></div><div class="">- Apple specifies a default point size of 144 in their docs (<a href="https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text/pointsize" target="_blank" class="">https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text/pointsize</a>). My guess is Apple assumes the traditional 1/72” point unit, which multiplies nicely to 144 and would result in Apple choosing a default size of 2”. Now Blender has no such notion of point size for fonts, leading to your question about how blender would specify this. One suggestion is to have Blender convert on export, such that it measures the height in designer units, converts to inches, then divides by 72.</div></div></blockquote><div class=""><br class=""></div><div class="">It would be good to get a definitive answer about this.<br class=""></div><div class=""> </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;" class="">- No idea. The docs refer to USD’s notion of a “stage unit”, but honestly having wdith/height makes no sense to me - seems like the runtime should figure this out. The doc also states, "The runtime ignores this value if `wrapMode` is singleLine.” I would (without understanding more) not export width/height at all and see what issues it causes</div></blockquote><div class=""><br class=""></div><div class="">From what I can tell, the width/height/depth properties are expressed in the "stage unit" indeed, which means for Blender simply Blender units (the exporter should ensure the USD scene is correctly set up to map it to meters on loading).<br class=""></div><div class=""> </div>Sybren<br class=""></div></div>
</div></blockquote></div><br class=""></div></body></html>