[x3d-public] draft X3D 4.1 prose for font files and libraries

[Andreas Plesch]

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.

On Sun, Mar 2, 2025 at 8:20 PM Michalis Kamburelis <michalis.kambi at gmail.com>
wrote:

> 1. As for the font fields mentioned by both Andreas and Holger (I
> understand you both use https://github.com/opentypejs/opentype.js/ in
> JS), I propose to keep it strict. In short: let's just use "fontFamily" (in
> your terminology, which I understand comes from
> https://github.com/opentypejs/opentype.js/ ), also known as
> "FT_FaceRec.family_name" (in the terminology of FreeType library,
> https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face
> ).
>
> Details:
>
> - fontFamily (like "Playwrite CA Guides") is like FT_FaceRec.family_name
> from FreeType I think,
> https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face
> .
>
>     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.
>
> - fontSubfamily like "Regular" seems to be like FT_FaceRec.style_name ,
> https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face
> .
>
>     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.
>
>     To know if the font is *really* bold or italic, rather use flags.
>
>     FreeType has "FT_FaceRec.style_flags" for this purpose. This is
> precise boolean information if given font is italic and/or bold.
>
>     Does opentype.js have something similar? Looking at code, they have
> fsSelection , can you access it?
> https://github.com/opentypejs/opentype.js/blob/aa8ad76467a27f086a19a7d3e12479a3d4fd93aa/src/font.mjs#L101
>
> - fullName that you show -- it seems like a concatenation of fontFamily +
> " " + fontSubfamily.
>
>     IOW, a concatenation of FT_FaceRec.family_name + " " +
> FT_FaceRec.style_name. The code confirms it's the default:
> https://github.com/opentypejs/opentype.js/blob/aa8ad76467a27f086a19a7d3e12479a3d4fd93aa/src/font.mjs#L21
> .
>
>     I think this should not be used. It's superfluous.
>
> 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.
>
>     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.
>
> The new "FontLibrary" is kind of a new concept.
>
> - 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.
>
> - 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
> https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website
> shows. What we will have in X3D is very different in approach and
> implementation.
>
> - 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.
>

Good point which did not really occur to me yet.


>
> - 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.
>

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.


>
> - 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 :)
>

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).


>
> - There are still missing pieces.
>
>      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).
>

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.


>     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.
>
> 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.
>
> 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.
>

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.

-Andreas

Regards,
> Michalis
>


-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250303/e52800bf/attachment-0001.html>