<div dir="ltr">Hello Don!<br><br>Answers inline below:<br><br>> Dick and I are only seeing three of them on your website this morning.<br><br>The <a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions">https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions</a> contains 4 questions, but one question is not in a dedicated subdirectory, I guess this was confusing :) It's in the file question_3_font_library_search.x3dv . <br><br>>  Question 1.  rephrased: does a child scene, Inlined by a parent scene, have access to FontLibrary fonts defined in the parent?<br>> <br>> Summary:  downward scope to descendant models.<br><br><div>OK. I think I'm fine with any answer here (as long as it's unambiguous and then encoded in spec). So FontLibrary in parent affects the child.</div><div><br></div><div>( It would be easier to implement if the FontLibrary scope was limited only to this file, but I can live with any choice. )</div><br>> Question 2.<br>> <br>> As indicated in our response to Question 2, we think it is possible but generally not desirable.<br>...<br>> We do not think that FontLibrary should be an X3DBindableNode (like Fog, Viewpoint, Background etc.)  However if an implementer wants to use a stack internally to implement such downward-looking scope, that is up to them.<br><br>OK, agreed. That is, FontLibrary in child *does not* affect the parent.<br><br>To be clear, I didn't suggest that it should be X3DBindableNode. FontLibrary is very different from X3DBindableNode. My comment in <a href="https://github.com/michaliskambi/x3d-tests/blob/master/font_library_questions/question_2/README.md">https://github.com/michaliskambi/x3d-tests/blob/master/font_library_questions/question_2/README.md</a> merely indicates that drawing analogies (which I did myself) between "how `Fog` works" and "how `FontLibrary` should work" has limits, because `Fog` has a "bindable" mechanism (only one is active at a time), while `FontLibrary` is not (many `FontLibrary` can be top-level and affect content). We are in agreement here as I understand, i.e. FontLibrary is *not* X3DBindableNode, this would make no sense.<br><br>>  Question 4.  Looks similar to question 2, using ExternProtoDeclare/ProtoInstance rather than Inline.  (But very tricky!  thanks!) <br>...<br>> FontLibrary fonts are available for reference and retrieval in the scene where the ProtoInstance is created at run-time.<br><br>OK, makes sense.<br><br>I see you also considered should the FontLibrary be allowed as top-level in prototype, and the conclusion is: it should not be. I agree. Keep things simple, FontLibrary only at top-level.<br><br>> We continue to think that FontLibrary as root node (with full X3DUrlObject functionality) is necessary for separation of concerns, i.e. keeping url networking separate from FontStyle presentation,  not overwhelming FontStyle functionality.  Thus, FontStyle.url is simply incomplete design, and FontStyle.fontLibrary is a more-correct alternative, if we want font scope limited to a single FontStyle node.<br><br>I have to say I still don't agree:<br><br><div>- "Separation of concerns" is unnecessary here, and we don't do such separation of concerns in any other place in X3D. We have ImageTexture with URL, and noone wants to introduce an ImageLibrary. We have AudioClip and other nodes. So FontLibrary is a very non-standard design, contrary to the rest of X3D.</div><div><br></div><div>    I see John noticed exactly the same thing. <br></div><div><br></div><div>    Note that ImageTextureAtlas ( <a href="https://create3000.github.io/x_ite/components/texturing3d/imagetextureatlas/">https://create3000.github.io/x_ite/components/texturing3d/imagetextureatlas/</a> ) is just a 3D texture. It's *not* like a (speculated) ImageLibrary, in the sense that it doesn't bring and new way to associate textures with appearances. ImageTextureAtlas is just a texture (and the association follows standard rules and 3D texture coordinates, from what I know).</div><br><div>- And this is causing significant implementation burden, with no significant benefit to users, IMHO. </div><div><br></div><div>     Because the fonts are associated by family name, the DEF/USE of FontLibrary is not useful, which is contrary to how one reuses e.g. textures, sounds. You also have explicit problems for implementations mentioned in this thread: now implementations need to parse font files to extract family names, to make the associations. Andreas said that X3DOM will likely not do this, and rely *only* on family name being spelled explicitly, from what I understand. <br></div><br>    And the answers to my questions from <a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions">https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions</a> are also additional work for implementations. We need to maintain the "available FontLibrary" for every X3D file and properly search them, accounting that a node may be in a child Inline, or in a prototype instance.<br><br>- And there's just not enough benefit from this design, IMHO... <br><br><div>    The common use-case, that really happens in reality (based on my experience speaking with Castle Game Engine users): """User has X3D with a text and a TTF file with a font (with single family and style). User wants to tell "use this TTF to render this text". """</div><div>       <br></div>    FontStyle.url is just solving this need in a direct way. We already have FontStyle to customize the font, it's obvious to users to look for an option to specify TTF there, it's trivial for implementations to support it. And font collections could be supported by simple `url "my-collection.ttc#123"`. And DEF/USE of FontStyle would make sense, and reuse the font file. That's exactly how our ImageTexture and other texture nodes work!<br>    <br>    In contrast, we go with FontLibrary, where the association is "by family name", which forces us to read font files beforehard, and to do additional logic "which FontLibrary to search".<br><div><br></div><div><div>    ( P.S. I deliberately give here an example with TTF. Although we like OTF, although we
 like WOFF... but in practice, most people still use the oldest standard, 
TTF, that's my statistics. Just because they can find a ton of TTF files on the Internet, and *every* font software can support TTF. )</div><br></div><div>Anyhow, I guess I repeated myself enough times :) I'm sorry, but I still really see FontLibrary as unnecessary complication, and I'm in favor of going back to FontStyle.url. <br></div><div><br></div><div>All the same, thank you for the discussion, for reading my long mails and answering testcases.</div><div><br></div><div>Regards,</div><div>Michalis</div></div>