[x3d-public] draft X3D 4.1 prose for font files and libraries
Michalis Kamburelis
michalis.kambi at gmail.com
Sun Mar 2 17:20:03 PST 2025
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.
- 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 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 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).
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.
Regards,
Michalis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250303/6fbda2c8/attachment.html>
More information about the x3d-public
mailing list