<div dir="ltr"><div>Agreed on most. If font names from font files are to be relevant it is probably necessary to go back to the actual font format specifications. From what I learned now is that they all share similar tables including a name table. Both freetype and opentype read these tables. Some minor comments below.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Mar 2, 2025 at 8:20 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</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 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/" target="_blank">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/" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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></blockquote><div><br></div><div>Good point which did not really occur to me yet. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>I was confused about this as well. But I now think the multiple urls are still supposed to contain the same file, and only serve as fallbacks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>There are ttc and otc font collections but I have not seen an example. Variable woff/ttf fonts can contain many styles (weights, obliqueness, condensed).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>I started to think about this as well but did not get far. I think the global FontLibrary concept may have been conceived to be similar to installing a new system font, perhaps even across browser instances (?). If that is the case then FontLibray node anywhere would affect any FontStyle. </div><div><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 dir="ltr"><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.</div></div></blockquote><div><br></div><div>FontStyle.fontLibrary would be very similar to FontStyle.url and could have other fields than url if needed. For example CSS has a "format" option lets a browser easily decide to not bother if a format is not supported.</div><div><br></div><div>-Andreas</div><div><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 dir="ltr"><div>Regards,</div><div>Michalis</div></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Andreas Plesch<br>Waltham, MA 02453</div></div></div></div>