<div dir="ltr"><div>1. As for the font fields mentioned by both Andreas and Holger (I understand you both use <a href="https://github.com/opentypejs/opentype.js/">https://github.com/opentypejs/opentype.js/</a> in JS), I propose to keep it strict. In short: let's just use "fontFamily" (in your terminology, which I understand comes from <a href="https://github.com/opentypejs/opentype.js/">https://github.com/opentypejs/opentype.js/</a> ), also known as "FT_FaceRec.family_name" (in the terminology of FreeType library, <a href="https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face">https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face</a> ).</div><div><br></div><div>Details:</div><div><br></div><div>- fontFamily (like "Playwrite CA Guides") is like FT_FaceRec.family_name from FreeType I think, <a href="https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face">https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face</a> .</div><div><br></div><div>    I say this should be used to match, precisely and exactly, the X3D "FontStyle.family" name. Let's not introduce any "fuzzy matching" to avoid matching family names differently in different browsers.</div><div><br></div><div>- fontSubfamily like "Regular" seems to be like FT_FaceRec.style_name ,<a href="https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face">https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face</a> .</div><div><br></div><div>    I propose: This has no use for FontLibrary implementations. This is a string description, that contains the information whether the font is italic, bold, but also other things like the difference "oblique vs italic", "book" style and other things that are not really interesting to font rendering. Just ignore it.</div><div><br></div><div>    To know if the font is *really* bold or italic, rather use flags. </div><div><br></div><div>    FreeType has "FT_FaceRec.style_flags" for this purpose. This is precise boolean information if given font is italic and/or bold.</div><div><br></div><div>    Does opentype.js have something similar? Looking at code, they have fsSelection , can you access it? <a href="https://github.com/opentypejs/opentype.js/blob/aa8ad76467a27f086a19a7d3e12479a3d4fd93aa/src/font.mjs#L101">https://github.com/opentypejs/opentype.js/blob/aa8ad76467a27f086a19a7d3e12479a3d4fd93aa/src/font.mjs#L101</a></div><div><br></div><div>- fullName that you show -- it seems like a concatenation of fontFamily + " " + fontSubfamily. </div><div></div><div><br></div><div>    IOW, a concatenation of FT_FaceRec.family_name + " " + FT_FaceRec.style_name. The code confirms it's the default: <a href="https://github.com/opentypejs/opentype.js/blob/aa8ad76467a27f086a19a7d3e12479a3d4fd93aa/src/font.mjs#L21">https://github.com/opentypejs/opentype.js/blob/aa8ad76467a27f086a19a7d3e12479a3d4fd93aa/src/font.mjs#L21</a> .</div><div><br></div><div>    I think this should not be used. It's superfluous.</div><div><br></div><div>2. To be frank, I think we're rushing too fast to the "FontLibrary" alternative. I can see Don likes it, and prefers it over "FontStyle.url", but I'm not certain. </div><div><br></div><div>    Admittedly I liked "FontStyle.url" simplicity, this design avoided some questions that we now ponder with "FontLibrary". It was kind of obvious what the "FontStyle.url" is doing. The only issue it had was that prose was missing clear statement "FontStyle.url overrides FontStyle.family, FontStyle.style". How it works seemed obvious. The DEF/USE of "FontStyle" nodes was functional to share fonts.</div><div><br></div><div>The new "FontLibrary" is kind of a new concept.</div><div><br></div><div>- We tell browsers to reuse fonts across the X3D document, if only their family name matches, but this is a new mechanism that sidesteps how X3D in general reuses things. Fonts are not reused using DEF/USE in this approach.</div><div><br></div><div>- We are also different in approach than CSS. The CSS doesn't require to match fonts by family names, rather it allows CSS authors to assign family names to font files. That's what my example <a href="https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website">https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website</a> shows. What we will have in X3D is very different in approach and implementation. </div><div><br></div><div>- We force X3D browsers to read the font files before a decision "I am going to render with this font" is made. A browser must read all fonts to match their family names.</div><div><br></div><div>- All fonts in "FontLibrary.url" have to be read (not only the first one) from what I understand. This was not obvious to me from first reading the spec of FontLibrary.</div><div><br></div><div>- I still didn't see a font file example that includes many families and/or many styles. Yet the wording of spec accounts for it. But all font files we all use and see are just single family, single style. If the font file with many families and/or many styles is really possible, please someone attach it :)</div><div><br></div><div>- There are still missing pieces. </div><div><br></div><div>     What happens if X3D file uses Inline to refer to another X3D file? Should the FontLibrary from parent X3D affect the child? That is, if FontLibrary is in parent X3D file, with family name "blah", and then inlined X3D file has FontStyle.family="blah". I propose not, to be simple (and because child's FontLibrary cannot affect parent).</div><div><br></div><div>    What happens if X3D file instantiates a prototype from external file, from EXTERNPROTO? And the parent X3D has FontLibrary with "blah". And the prototype has FontStyle.family="blah". Should be instantiated node be affected by the FontLibrary ? Again, I propose "it should not be". Each X3D should have its own font library.</div><div><br></div><div>To be clear, I do see one advantage of FontLibrary. It means that "FontStyle.family" and "FontStyle.style" are not "overridden". Rather, they become a way to select a font provided on the FontLibrary list.</div><div><br></div><div>But I'm admittedly not convinced whether the "FontLibrary" is a better solution. For me, right now, I would lean towards "FontStyle.url" solution, not "FontLibrary". The "FontStyle.url" is just simpler, both to understand and to implement. <br></div><div><br></div><div>Regards,</div><div>Michalis</div></div>