[x3d-public] draft X3D 4.1 prose for font files and libraries
Andreas Plesch
andreasplesch at gmail.com
Tue Mar 4 07:54:59 PST 2025
https://developer.mozilla.org/en-US/docs/Web/CSS/font-variation-settings
has css details.
The most commonly implemented axes tags such as "wght" and "ital" are
registered but there can be any number of custom axes.
One way to support variable or variation fonts would be to remain limited
to the standard X3D style field values and map transparently those to
registered axes:
BOLD => "wght": 700 (
https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight#common_weight_name_mapping
)
ITALIC => "ital" : 1
PLAIN => default or "wght": 400; "ital": 0
BOLDITALIC => "wght": 700; "ital": 1
This would be helpful in that variable font files can be used for the most
common situations. X3D browser could already choose to do that
transparently if the font file has a variable font.
Another, common and therefore registered axis is "wdth" which allows for
condensed or expanded options. The value is in percent (100 is normal). The
CSS equivalent property is called "font-stretch".
A general way to select a setting from a variable font could be a MFString
variation field with name value pairs separated by a colon or space: '
"wght: 900" "ital: 1" "wdth: 150" ' . There may be better ways to provide
name-value pairs.
It would be the author's responsibility to choose axes and values which are
supported by the font.
But such a field may be too closely linked to variable fonts only, and a
higher level abstraction may be preferable.
Variable fonts also have "named instances" which are preconfigured axes
sets with a name. CSS has a property for those but this property is not
supported by web browsers.
-Andreas
On Tue, Mar 4, 2025 at 8:18 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:
> During this design stage it would be the time to consider variable fonts.
>
>
> https://stackoverflow.com/questions/57111097/does-freetype-support-variable-fonts
>
> They are pretty common now.
>
> They would require in effect an n-dimensional style.
>
> They may be not too hard to support. The difficulty may be mostly in
> designing fields for n axes and axes values.
>
> Andreas
>
> On Tue, Mar 4, 2025, 7:44 AM Michalis Kamburelis <michalis.kambi at gmail.com>
> wrote:
>
>> 1. I looked how FreeType supports font collections. https://freetype.org/
>> indeed says it can handle TTC, OTC.
>>
>> API: we can pass "index" to various functions (like FT_New_Face),
>> which seens to be an index into the font collection.
>>
>> I didn't find any way to query the available count inside a given
>> font collection (file) -- it seems that application is just expected to
>> know the index, i.e. it is specified by the user like "use font from this
>> amazing-font.ttc file, index 1". It seems to me that "enumerate all fonts
>> within a font collection" is not a typical operation, I actually don't know
>> how to do it yet.
>>
>> 2. I am afraid we go into something overly complicated with FontLibrary,
>> both to use (for authors) and to implement.
>>
>> The current design of FontLibrary assumes that font collections (that
>> include many families and/or many font styles within a single file) are a
>> common use-case. But this is not the case, it seems we all confirmed this
>> in this thread. In practice, font files are TTF / OTF / WOFF with one
>> family and one style. And opentype.js does not support font collections.
>> FreeType suppprts them, but I'm not sure how to enumerate them all.
>>
>> The new prose accounts for this, by allowing various options... and
>> being needlessly complicated, IMHO. So I feel we arrived at a complicated
>> spec, without much benefit.
>>
>> If I understand the new proposal (
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontLibrary
>> ) right:
>>
>> The browser should read the first accessible font file from
>> FontLibrary.url.
>>
>> This font file, referenced by FontLibrary.url, can be:
>>
>> - Multiple font families inside. If the first accessible thing on
>> FontLibrary.url is a font collection (TTC, OTC, or a collection inside
>> WOFF). And then "FontLibrary.family" cannot be used (as it would make no
>> sense).
>>
>> - Single font family (with multiple styles or one style). And then
>> (according to spec) "FontLibrary.family" is allowed (to override family
>> name from font file content), but optional.
>>
>> The connection between FontLibrary and FontStyle can be done in 2
>> ways, as I understand:
>>
>> - If FontStyle.fontLibrary = NULL, then match the family name from
>> FontStyle.family, using all loaded fonts from FontLibrary nodes. (Should it
>> take into account also FontLibrary nodes mentioned only in some
>> FontStyle.fontLibrary? or only top-level FontLibrary nodes? and what about
>> my questions with Inline and EXTERNPROTO cases?)
>>
>> - If FontStyle.fontLibrary <> NULL, then match the family name from
>> FontStyle.family, using only the indicated FontLibrary node.
>>
>> This is also quite different to what CSS is doing. At least to what I
>> shown in
>> https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website
>> .
>>
>> 3. I really propose we go back to "FontStyle.url", and scratch the
>> "FontLibrary" node design.
>>
>> We can still add optional support font collections (noting that
>> opentype.js cannot implement this), but allowing a trivial `#<index>` at
>> the font file URL. Like
>>
>> FontStyle {
>> url "my-font-collection.ttc#1"
>> }
>>
>> And in the most common case, it is simple:
>>
>> FontStyle {
>> url "my-font-file.ttf"
>> }
>>
>> Advantage of FontStyle.url: The common use-case, which is: font file
>> is one family with one style, remains now trivial. All my questions from AD
>> 2 disappear :) And all implementations can easily support it.
>>
>> Regards,
>> Michalis
>>
>> pon., 3 mar 2025 o 21:00 Andreas Plesch <andreasplesch at gmail.com>
>> napisał(a):
>>
>>> Thanks, I think that captures the design ideas well.
>>>
>>> I think font collection files are very rare. They are explicitly not
>>> supported by the opentype.js library (
>>> https://github.com/opentypejs/opentype.js/discussions/668). But they do
>>> exist and are supported by the freetype library. So it could become
>>> optional for x3d browsers to support those or not, perhaps via component
>>> levels. There seem to be many tools which can split a font collection file
>>> into separate, single font files.
>>>
>>> Following CSS, one idea to deal with font collections (.ttc, .otc files,
>>> also as embedded in woff) would be to require an author to select a
>>> specific, single font from a collection via url# fragment syntax:
>>>
>>> url=' "
>>> https://server/path/largeExoticFontLibrary.ttc#Postscript_name_of_FontA"
>>> '
>>>
>>> CSS uses the Postscript name (format defined in a RFC,
>>> https://www.rfc-editor.org/rfc/rfc8081#section-4.2) for selection
>>> according to the CSS spec.
>>>
>>> That way font collection files can be treated the same as single font
>>> files. I do not know if or how freetype manages font collection files.
>>> Also, I do not know if the CSS syntax above is supported by web browsers
>>> (but I would expect them to,
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1529652 says no).
>>>
>>> For global FontLibrary scope, in my opinion, the FontLibrary.family
>>> field should not be optional but required, again following the CSS pattern.
>>> The family name is easy for an author to add, and makes it unambiguous for
>>> a x3d browser to match, without first downloading the file for inspection.
>>> This then would mean that an empty family field does not guarantee a match
>>> although a browser may use the internal font name(s) as a fallback.
>>>
>>> With the url selection mechanism above, a global FontLibray node may not
>>> be necessary at all. But it remains questionable if there is enough library
>>> support for font collection files in general.
>>>
>>> -Andreas
>>>
>>>
>>> On Mon, Mar 3, 2025 at 12:26 PM Brutzman, Donald (Don) (CIV) <
>>> brutzman at nps.edu> wrote:
>>>
>>>> Excellent analysis together is much appreciated.
>>>>
>>>> To facilitate continue discussion on this highly detailed discussion, I
>>>> have a applied some additions to the "design draft" specification prose:
>>>>
>>>> - Add FontLibrary family field
>>>> - SFString [in,out] family "" (under
>>>> consideration)
>>>> - The *family* field provides an identifying name for the
>>>> associated font library. This field provides a reference label for the
>>>> *family* field in a corresponding FontStyle or ScreenFontStyle
>>>> node.
>>>> - (Editors note: this approach is similar to how CSS can
>>>> identify font family for use in HTML.)y
>>>> - (Editors note: key design question for whether global scope is
>>>> needed: can a single font file contain more than one font?)
>>>> - Added description for EXAMPLE 1.
>>>> - FontLibrary node with global scope, where font family
>>>> identification is deduced from name metadata within the font file.
>>>> - Added second example, adapting Holgers design-exploration
>>>> example
>>>> - EXAMPLE 2. FontLibrary nodes each having local scope within
>>>> parent FontStyle node, where font family identification is provided by
>>>> matching values for corresponding *family *fields.
>>>> - # example derived from FontLibrary.x3dv
>>>> <https://create3000.github.io/preview/playground/?url=https://gist.githubusercontent.com/create3000/6d3992dea7e641bb59645684ca468ce7/raw/a63e66e23b305478fbfdee9e67d7db9cad1f8e72/FontLibrary.x3dv> (Holgers
>>>> example)
>>>> - Moved FontLibrary nodes as * fontLibrary *field in respective
>>>> FontStyle nodes, added FontLibrary DEF and matching *family *
>>>> fields.
>>>> - Screenshot attached - wow, X_ITE rendered it correctly without
>>>> further software adjustment! 🙂
>>>> -
>>>> - X3D 4.1 Draft Architecture, clause 15 Text component, 15.4.1
>>>> *FontLibrary*
>>>> -
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontLibrary
>>>> - X3D 4.1 Draft Architecture, clause 15 Text component, 15.4.2
>>>> *FontStyle*
>>>> -
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle
>>>>
>>>>
>>>> Hopefully this is capturing and synthesizing everyone's intent.
>>>> Further clarifications and refinement are of course welcome.
>>>>
>>>> Onward we go, getting clearer through scrutiny during each pass. Have
>>>> fun with X3D FontLibrary!
>>>>
>>>>
>>>> all the best, Don
>>>>
>>>> --
>>>>
>>>> Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>>
>>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>>> +1.831.656.2149
>>>>
>>>> X3D graphics, virtual worlds, navy robotics
>>>> https://faculty.nps.edu/brutzman
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* Andreas Plesch <andreasplesch at gmail.com>
>>>> *Sent:* Monday, March 3, 2025 4:06 AM
>>>> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>>> *Cc:* Holger Seelig <holger.seelig at yahoo.de>; Extensible 3D (X3D)
>>>> Graphics public discussion <x3d-public at web3d.org>
>>>> *Subject:* Re: [x3d-public] draft X3D 4.1 prose for font files and
>>>> libraries
>>>>
>>>> Similar to Michalis viewpoint, I also see advantages of a FontStyle.url
>>>> (or FontStyle.fontLibrary) field over a global FontLibrary node. x3dom
>>>> currently does not need to download, parse or render font files at all
>>>> since this can all be delegated to the web browser in which x3dom is
>>>> necessarily embedded. It does not currently need a library such as
>>>> opentype.js and can take advantage of the rapid pace of web browser
>>>> development. For example, x3dom could use variable fonts or color fonts.
>>>>
>>>> On Sun, Mar 2, 2025 at 6:26 PM Brutzman, Donald (Don) (CIV) <
>>>> brutzman at nps.edu> wrote:
>>>>
>>>> An optional *family* field might be helpful for FontLibrary but
>>>> probably only when a single font family is contained in that file.
>>>>
>>>>
>>>> True, a FontLibrary.family field would only be helpful in that case.
>>>> However, the vast majority of font files only contain one font family. In
>>>> fact, I have not come across any font file which contains multiple families
>>>> (tfc,otc). Variable fonts have one family but multiple styles and weights.
>>>> My suggestion would be to strongly recommend to authors to provide a
>>>> FontLibrary.family name. This guarantees correct matching with a FontStyle.
>>>> In fact, x3dom would effectively require use of the field.
>>>>
>>>> Font files can also be collections according to WOFF2 Recommendation.
>>>>
>>>> - WOFF File Format 2.0, W3C Recommendation, 08 August 2024
>>>> - Status of This Document
>>>> - "The WOFF 2.0 specification is implemented in all major browsers,
>>>> and is widely used on production websites. It supports the entirety of the
>>>> TrueType and OpenType specifications, including Variable fonts, Chromatic
>>>> fonts, and font Collections."
>>>> - https://www.w3.org/TR/WOFF2
>>>> - 4.2. Collection directory format
>>>> - "If input font is a collection, the table directory
>>>> <https://www.w3.org/TR/WOFF2/#table_dir_format> contains a single
>>>> entry for each unique table in the entire collection, regardless of whether
>>>> a table is shared among different fonts in a collection or not. Thus, the
>>>> table directory for a font collection compressed with WOFF2 comprises all
>>>> tables from all fonts contained in the font collection file."
>>>> - https://www.w3.org/TR/WOFF2/#collection_dir_format
>>>>
>>>>
>>>> My understanding is that this collection capability is only used by
>>>> some Asian fonts where the same glyph can be shared by different font
>>>> families, for different characters.
>>>> I am not sure how CSS or freetype is currently dealing with this
>>>> situation. It should be insightful to find out. Found out something for
>>>> CSS, see below.
>>>>
>>>> We might be able to define this so that it works both ways, either with
>>>> matching * family *names or not... for example,
>>>>
>>>> - a FontLibrary with a woff url referring to a single font might be
>>>> an unambiguous child of FontStyle as FontStyle.fontLibrary. This approach
>>>> completely avoids any need to check for precise *family *naming
>>>> matches., the FontStyle only uses that contained font
>>>>
>>>> Yes, I think this should work fine.
>>>>
>>>>
>>>> - a FontLibrary with a woff url referring to a collection of fonts,
>>>> which are each named and matchable, might also be used for matching with
>>>> FontStyle.family.
>>>>
>>>>
>>>> I fear we do not know enough about font files with a collection of
>>>> fonts are intended to be used.
>>>>
>>>>
>>>> - DEF/USE declarations allow us to have both global and restricted
>>>> availability as desired by the author. In other words,
>>>> - a FontLibrary might not be referenced as a field and have global
>>>> scope (the prose that is currently in the 4.1 design draft), or else
>>>> - a FontLibrary might also be the child of a FontStyle node
>>>> (something we might add to the 4.1 design draft).
>>>>
>>>>
>>>>
>>>> Seems like we might be able to "take the fork in the road" here, giving
>>>> authors flexibility. Hmmm...
>>>>
>>>> Somewhat related: since staying aligned with CSS practice is important,
>>>> here is an example of further interest. The following provides a clear
>>>> example of how an author can define CSS so that html can use four different
>>>> woff files for plain, bold, bold-italic, italic markup (using <b> and <i>
>>>> elements). Food for thought perhaps.
>>>>
>>>> - How do I use .woff fonts for my website?
>>>> -
>>>> https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website
>>>>
>>>>
>>>>
>>>> This is an old but still working and good example.
>>>> https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face and
>>>> https://drafts.csswg.org/css-fonts/#font-face-rule have more details.
>>>> Note how the font-family is a given custom name which is then used in
>>>> other css rules.
>>>> https://drafts.csswg.org/css-fonts/#font-face-src-loading has the
>>>> syntax of how to select a font from a collection, using its Postscript name
>>>> (so not the family name or full name).
>>>>
>>>> All the best, -Andreas
>>>>
>>>>
>>>> all the best, Don
>>>>
>>>> --
>>>>
>>>> Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>>
>>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>>> +1.831.656.2149
>>>>
>>>> X3D graphics, virtual worlds, navy robotics
>>>> https://faculty.nps.edu/brutzman
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* x3d-public <x3d-public-bounces at web3d.org> on behalf of Andreas
>>>> Plesch via x3d-public <x3d-public at web3d.org>
>>>> *Sent:* Sunday, March 2, 2025 1:39 PM
>>>> *To:* Holger Seelig <holger.seelig at yahoo.de>
>>>> *Cc:* Andreas Plesch <andreasplesch at gmail.com>; X3D <
>>>> x3d-public at web3d.org>
>>>> *Subject:* Re: [x3d-public] draft X3D 4.1 prose for font files and
>>>> libraries
>>>>
>>>> Thanks. That is what I thought. But should this mapping be part of the
>>>> X3D spec. ? Or should this mapping be left at the digression of the X3D
>>>> browser as a best effort ? Eg. most browsers may use fontFamily to
>>>> associate a FontStyle.family with but some browsers may prefer to use
>>>> fullName and expect FontStyle.family to match that. Should the matching be
>>>> case sensitive ?
>>>>
>>>> I think it would be cleaner to not have to rely on matching font names.
>>>> A FontLibrary.family would allow that and not require any changes to
>>>> FontStyle as it is defined.
>>>>
>>>> -Andreas
>>>>
>>>> On Sun, Mar 2, 2025 at 3:44 PM Holger Seelig <holger.seelig at yahoo.de>
>>>> wrote:
>>>>
>>>> fontFamily - is equal to the FontStyle.family field
>>>> fontSubfamily - is equal to FontFamily.style field but can contain
>>>> spaces and any kind of chars or even special chars
>>>> fullName - could be usefull to directly access a specific font
>>>>
>>>> This means more or less that the FontFamily.style field should be able
>>>> to have more possible values than the current 4 (PLAIN, BOLD, ITALIC,
>>>> BOLDITALIC) so that values like "Regular", "Oblique", "Outline", "Outline
>>>> Bold" or what ever the Font Designer wishes it should be called and written.
>>>>
>>>> Best regards,
>>>> Holger
>>>>
>>>> --
>>>> Holger Seelig
>>>> Leipzig, Germany
>>>>
>>>> holger.seelig at yahoo.de
>>>> https://create3000.github.io/x_ite/
>>>>
>>>> Am 02.03.2025 um 13:21 schrieb Holger Seelig via x3d-public <
>>>> x3d-public at web3d.org>:
>>>>
>>>> It seems I was wrong with my last email.
>>>>
>>>> I created a reference implementation of FontLibrary node to test and
>>>> play with.
>>>>
>>>> It is available at:
>>>>
>>>> https://create3000.github.io/test/?url=https://gist.githubusercontent.com/create3000/6d3992dea7e641bb59645684ca468ce7/raw/a63e66e23b305478fbfdee9e67d7db9cad1f8e72/FontLibrary.x3dv
>>>>
>>>> Best regards,
>>>> Holger
>>>>
>>>> --
>>>> Holger Seelig
>>>> Leipzig, Germany
>>>>
>>>> holger.seelig at yahoo.de
>>>> https://create3000.github.io/x_ite/
>>>>
>>>> Am 02.03.2025 um 05:26 schrieb Andreas Plesch via x3d-public <
>>>> x3d-public at web3d.org>:
>>>>
>>>> Ok, I think these explanations make the intention very clear.
>>>>
>>>> On Sat, Mar 1, 2025 at 3:29 PM Brutzman, Donald (Don) (CIV) <
>>>> brutzman at nps.edu> wrote:
>>>>
>>>> Thanks for careful scrutiny and questions. Overall responses:
>>>>
>>>> 1. We have not seen a need for FontLibrary to be referenced in the
>>>> field of any other node. It adds to the fonts available in the browser.
>>>>
>>>> Then a FontLibrary node needs to be able to be a root node:
>>>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/concepts.html#Rootnodes
>>>> So it could be a ChildNode or another class of root nodes.
>>>>
>>>>
>>>> 1.
>>>> 2. If someone has a use case where FontLibrary needs to be
>>>> specifically referred to by individual FontStyle or ScreenFontStyle nodes,
>>>> please state it.
>>>>
>>>> This would clearly associate a font with an individual FontStyle and
>>>> avoid mistakes.
>>>> In rare cases there may be two different fonts which have the same
>>>> family name. There is no central registry for font family names.
>>>>
>>>>
>>>> 1.
>>>> 2. Since fonts themselves change so infrequently, keeping
>>>> FontLibrary scope global and not requiring reloads of any given url (local
>>>> file or online) seems sensible.
>>>>
>>>> Rereferencing by DEF/USE a FontStyle.fontLibrary would not require
>>>> reloads. In terms of loading efficiency it does not matter if the scope is
>>>> Scene or FontStyle/Text.
>>>>
>>>>
>>>> 1.
>>>> 2. Since X3DUrlNode functionality of the url (and related) fields
>>>> offers so much functionality, making X3DUrlNode an abstract interface for
>>>> FontLibrary adds much common functionality found in other X3DUrlNode nodes
>>>> that have url functionality (Anchor, ImageTexture, Inline, and others).
>>>> This simplifies implementations, keeps functionality consistent, and
>>>> provides well-understood semantics to authors. Furthermore, allowing an
>>>> author to selectively load a new font file at run time offers greater
>>>> flexibility for textual presentation and animation
>>>>
>>>>
>>>>
>>>>
>>>> 1.
>>>> 2. Having url and run-time capabilities means that FontLibrary
>>>> would be an X3D node, not an X3D statement.
>>>>
>>>> True. The statement role just seems to fit better as FontLibray would
>>>> not be referenced by any field. Perhaps there is a way to adopt the url
>>>> field for such a statement.
>>>>
>>>>
>>>> 1.
>>>> 2. The availability of DEF and USE capabilities is perhaps not
>>>> needed for regular use. Nevertheless it might provide interesting options
>>>> if an author wants to use FontLibrary in combination with Script or
>>>> ProtoDeclare/ExternProtoDeclare functionality. For example, a scene might
>>>> have a Script or ProtoInstance that uses a specific custom
>>>> ExternProtoDeclare reference. Several possibilities for advanced authoring
>>>> here, just taking advantage of existing X3D flexibility and extensibility.
>>>>
>>>> See *response* paragraphs inserted below for specific replies.
>>>>
>>>>
>>>> *response: *We are thinking that if inconsistencies exist between a
>>>> specified FontStyle family field and the font file, then such cases are
>>>> best handled on a best-effort basis by browsers without further complex
>>>> (and possibly contradictory) guidance in specification prose. Perhaps this
>>>> stance should be a NOTE?
>>>>
>>>>
>>>> Another source of conflict is the font family name. While most (perhaps
>>>> not all) font files contain a correct family name, it is difficult to
>>>> extract and requires a library. For example, web browsers do not extract
>>>> the family name from a font file, and therefore do not rely on such an
>>>> extracted name. An author may not even know the exact font name as
>>>> contained in a font file. The family names shown in online font collections
>>>> may not match exactly what is contained in a file.
>>>> Don's example scene is actually a victim of this potential for
>>>> confusion. The family name Playwright_CA_Guides is in reality not the
>>>> same name as given in the woff2 file. I think it is Playwright CA
>>>> Guides. I may be responsible for this since I used it in an example
>>>> but it shows how quickly this can go wrong.
>>>> The solution in CSS is to allow authors to define their own family name
>>>> for the font given in the font file.
>>>> The X3D equivalent would be to add a SFString FontLibrary.family field
>>>> which would be the authoritative family name. The family name in the font
>>>> file would be ignored.
>>>> Then the author can use the same name in the FontStyle.family field.
>>>> This starts to sound a lot like DEF/USE names which would work similarly
>>>> for a Font Style.font Library field node.
>>>>
>>>> So please consider adding a SFString FontLibrary.family field to
>>>> FontLibrary.
>>>>
>>>> I think x3dom may not be able to fully implement FontLibrary if
>>>> extraction of the family name from the font file is necessary since the
>>>> size of the needed libraries may not be commensurate with the added benefit.
>>>>
>>>> How does FontLibrary define a "collection of one or more font families"
>>>> ? Is there an example of a font file containing more than one font family ?
>>>>
>>>> "An empty *url* list indicates that the default set of fonts provided
>>>> by the browser are used."
>>>>
>>>> The url field always exists but can be empty. So is optional and could
>>>> be removed.
>>>> Is that case different from not providing a FontLibrary node at all ?
>>>> If not, perhaps make this stronger: "list is equivalent to not including
>>>> the FontLibrary node."
>>>>
>>>> Andreas
>>>>
>>>> P.S. Interesting reference
>>>>
>>>> - Google Fonts: Using type in AR & VR
>>>> - https://fonts.google.com/knowledge/using_type_in_ar_and_vr
>>>>
>>>>
>>>> all the best, Don
>>>> --
>>>> Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>>> +1.831.656.2149
>>>> X3D graphics, virtual worlds, navy robotics
>>>> https://faculty.nps.edu/brutzman
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* x3d-public <x3d-public-bounces at web3d.org> on behalf of Andreas
>>>> Plesch via x3d-public <x3d-public at web3d.org>
>>>> *Sent:* Saturday, March 1, 2025 6:45 AM
>>>> *To:* X3D Graphics public mailing list <x3d-public at web3d.org>
>>>> *Cc:* Andreas Plesch <andreasplesch at gmail.com>
>>>> *Subject:* Re: [x3d-public] draft X3D 4.1 prose for font files and
>>>> libraries
>>>>
>>>> I basically had the same questions as Michalis.
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Date: Sat, 1 Mar 2025 05:52:24 +0100
>>>> From: Michalis Kamburelis <michalis.kambi at gmail.com>
>>>>
>>>> As for FontLibrary,
>>>>
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#FontLibrary
>>>> : I admit I don't understand this proposal (yet).
>>>>
>>>> 1. Where is the FontLibrary actually used? It doesn't seem you can
>>>> refer to
>>>> a FontLibrary node in any way. It's also not X3DChildNode, so you cannot
>>>> just place it in groups.
>>>>
>>>>
>>>> This is a big missing piece.
>>>> After some thought, I think the idea is to give the X3D browser
>>>> information on how to render fonts which are referenced in a
>>>> FontStyle.family field.
>>>> One option is to think of it not as a Node but as a Statement
>>>> describing a resource available to the X3D browser in general.
>>>> Another option is to make it part of WorldInfo as a value for a new
>>>> WorldInfo.fonts field ?
>>>> The idea came up as an alternative to a FontStyle.url field, so see
>>>> below.
>>>>
>>>> *response:* See above.
>>>>
>>>> 2. The sentence """If present, only the first active font library
>>>> retrieved
>>>> from the url list shall be used."""" --- What is the meaning of word
>>>> "used"
>>>> in this sentence? Used for what?
>>>>
>>>>
>>>> What is 'active' ? Probably accessible
>>>>
>>>> "Used": ?
>>>>
>>>> *response: *We were trying to emphasize that only one font file can be
>>>> loaded by a FontLibrary node. The functionality of an X3D url is
>>>> unchanged, the first working address in the list is used. This is trying
>>>> to complement the more general wording in 9.3.2 concisely... Specific
>>>> wording suggestions always welcome.
>>>>
>>>> - X3D 4.1 (draft) Architecture, clause 9 Networking component,
>>>> 9.3.2 X3DUrlObject
>>>> - "All *url* fields can hold multiple string values. The strings in
>>>> these fields indicate multiple locations to search for data in the order
>>>> listed. If the X3D browser cannot locate or interpret the data specified by
>>>> the first location, it shall try the second and subsequent locations in
>>>> order until a location containing interpretable data is encountered. X3D
>>>> browsers only have to interpret a single string. If no
>>>> interpretable locations are found, the node type defines the resultant
>>>> default behaviour."
>>>> -
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#X3DUrlObject
>>>> X3D Architecture 4.1 draft — ISO/IEC 19775-1:202x — 9 Networking
>>>> component
>>>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#X3DUrlObject>
>>>> 9.2 Concepts 9.2.1 URLs, URNs and URIs. A URL (Uniform Resource
>>>> Locator) is a form of Universal Resource Identifier (URI) described in that
>>>> specifies a file located on a particular server and accessed through a
>>>> specified protocol (such as file:, http: or https:).In this document, the
>>>> upper-case term URL refers to a Uniform Resource Locator, while the
>>>> italicized lower-case version url refers to ...
>>>> www.web3d.org
>>>>
>>>>
>>>> 3. """Individual font library files can be used by multiple FontStyle
>>>> nodes
>>>> in a scene.""" -- How? FontStyle does not refer to FontLibrary. And I
>>>> understand in this version, FontStyle would not have its own
>>>> FontStyle.url
>>>> field.
>>>>
>>>> Did you maybe want to add a field like "SFNode FontLibrary
>>>> fontLibrary" to FontStyle or Text? Or make FontLibrary a X3DChildNode?
>>>>
>>>>
>>>> That was my first thought as well but see above.
>>>> A simple way to make a FontLibrary url available to multiple FontStyle
>>>> nodes is by DEF/USE.
>>>> A FontStyle.fontLibrary field is preferred over a global scope since it
>>>> clearly associates a font to a FontStyle/Text.
>>>> It is better not to have to rely on the family name to identify a font.
>>>> Having to rely on the family name is more error prone for both the author
>>>> and the browser.
>>>>
>>>> *response: *the cyan text for FontStyle draft prose shows the
>>>> less-desirable alternative. Have added strikethrough (using html <del>
>>>> tag) and better description to indicate that we moved url fields from
>>>> FontStyle to FontLibrary). The cyan alternative is there now for
>>>> comparison, essentially the prose is the same. Hopefully the draft prose
>>>> is clearer now, with no duplication of functionality.
>>>>
>>>> *response: *We are thinking that if inconsistencies exist between a
>>>> specified FontStyle family field and the font file, then such cases are
>>>> best handled on a best-effort basis by browsers without further complex
>>>> (and possibly contradictory) guidance in specification prose. Perhaps this
>>>> stance should be a NOTE?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 4. A testcase, preferably many testcase(s), explaining the FontLibrary
>>>> usage (X3D files + intended rendering) would very helpful. (Same goes
>>>> for
>>>> the previous proposal actually.) Please provide testcases along with
>>>> spec
>>>> prose -- they make the intention more obvious.
>>>>
>>>>
>>>> Including edge cases if possible.
>>>>
>>>> * response*: Agreed. We will review the following simple example in
>>>> our next editors meeting. More examples are welcome from people
>>>> contributing to this list.
>>>> EXAMPLE
>>>>
>>>> FontLibrary { # example derived from TextHaveFunWithX3D.x3d <https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/dc9111dcd106f1a69d567ceca8f52701/raw/8cdf9764f11e08b5f541dee487fc0811bb0cf927/FontHaveFunWithX3D.x3d>
>>>> url ["MjQamj1kuP_soQ3o-rysO9Ci_8oJlIUUInI.woff2"
>>>> "https://fonts.gstatic.com/s/playwritecaguides/v1/MjQamj1kuP_soQ3o-rysO9Ci_8oJlIUUInI.woff2"]
>>>> }
>>>> Shape {
>>>> # ☺ = ☺ smiley face emoticon, and "" means skip a line
>>>> geometry Text {
>>>> string [ "Have fun" "with X3D!" "" ":) ☺" ]
>>>> fontStyle FontStyle {
>>>> spacing 1.5
>>>> family=["Playwright_CA_Guides"]
>>>> justify [ "MIDDLE" "MIDDLE" ]
>>>> }
>>>> }
>>>> }
>>>>
>>>>
>>>> Overall, so far, I admit FontLibrary is confusing to me, I don't know
>>>> what
>>>> it means. The previous proposal (extending FontStyle) seems more
>>>> straightforward -- a few people (including me) had feedback, but it
>>>> seems
>>>> that we all "got the intention" of FontStyle.url correctly, we just
>>>> pointed
>>>> some things to improve in wording.
>>>>
>>>>
>>>> One advantage of a FontLibrary (or perhaps just 'Font') node would be
>>>> DEF/USE.
>>>>
>>>> As mentioned multiple times, the spec. should include language that the
>>>> FontStyle.style field may be ignored if a FontLibrary url is accessible as
>>>> in most cases that url will only provide data for one specific style..
>>>>
>>>> Regards, -Andreas
>>>>
>>>> *response: *the presence of the css style field might add a whole new
>>>> level of sophistication and possible edge cases.
>>>>
>>>> This again sounds like a rationale for a NOTE in the specification
>>>> specifically pointing out that browsers have latitude to handle ambiguous
>>>> cases before falling back to default font... Might be obvious/redundant or
>>>> might be helpful.
>>>>
>>>> Hope these responses help us converge, again thanks for together
>>>> thinking things through. v/r Don
>>>>
>>>>
>>>> pt., 28 lut 2025 o 19:56 Brutzman, Donald (Don) (CIV) via x3d-public <
>>>> x3d-public at web3d.org> napisa?(a):
>>>>
>>>> > Thanks everyone for responses, implementation improvements, technical
>>>> > details, and many insights.
>>>> >
>>>> > First positive takeaway: WOFF File Format 2.0 is the clear
>>>> preference to
>>>> > WOFF 1.0.
>>>> >
>>>> > WOFF File Format 2.0, W3C Recommendation, 08 August 2024
>>>> >
>>>> > - "Abstract. Based on experience with WOFF 1.0, which is widely
>>>> > deployed, this specification was developed to provide improved
>>>> compression
>>>> > and thus lower use of network bandwidth, while still allowing fast
>>>> > decompression even on mobile devices. This is achieved by
>>>> combining a
>>>> > content-aware preprocessing step and improved entropy coding,
>>>> compared to
>>>> > the Flate compression used in WOFF 1.0."
>>>> > - https://www.w3.org/TR/WOFF2
>>>> >
>>>> > Clearly, from recent excellent emails, there are many
>>>> implementer-specific
>>>> > issues and interactions when adding font files that are good to know
>>>> about,
>>>> > but don't necessarily need to be expressed in an X3D model (or the X3D
>>>> > Architecture specification).
>>>> >
>>>> > Dick and I worked further today to assess whether separation of font
>>>> files
>>>> > from FontStyle node into a FontLibrary node was the preferred to
>>>> represent
>>>> > this information in an X3D model. We also repeated WOFF
>>>> Recommendation's
>>>> > use of term "collection" as part of a *FontLibrary *definition.
>>>> >
>>>> > - The FontLibrary node specifies a collection of one or more font
>>>> > family definitions. A font family may include one or more related
>>>> font
>>>> > style definitions. FontLibrary provides the ability to selectively
>>>> load
>>>> > font files for use by FontStyle
>>>> > <
>>>> https://outlook.office.com/mail/id/AAkALgAAAAAAHYQDEapmEc2byACqAC%2FEWg0AN5ikByHYYkeveIfklhUi1gAG%2Blh21AAA?nativeVersion=1.2025.219.400#FontStyle>
>>>> and
>>>> > ScreenFontStyle
>>>> > <https://outlook.office.com/mail/id/layout.html#ScreenFontStyle>
>>>> nodes.
>>>> >
>>>> > FontLibrary node pros (meaning separation of font files from FontStyle
>>>> > node):
>>>> >
>>>> > - Keeps existing (and fairly complex) FontStyle implementations
>>>> > unchanged
>>>> > - Separation of loading and presentation functionality between two
>>>> > nodes
>>>> > - FontLibrary simply adds to the selection of fonts available, and
>>>> > retains emphasis of *family *and *style *fields within a given
>>>> > FontStyle node.
>>>> > - If separate font files redefine a given family (with the same
>>>> name),
>>>> > then addition of *enabled *field might allow authors to determine
>>>> > which of them is relevant. However *enabled *field can be
>>>> considered
>>>> > redundant (since changing url has same effect).
>>>> > - Alternative approach to use of an *enabled *field, we might also
>>>> > need to add a sentence such as
>>>> > - "If a font family is redefined by multiple FontLibrary nodes,
>>>> then
>>>> > the first defined family is used."
>>>> > - (or we can remain silent and let browser implementations sort
>>>> > that out)
>>>> >
>>>> > FontLibrary node cons (meaning bundle all url functionality in
>>>> FontStyle):
>>>> >
>>>> > - Closer coupling of *family *field and font files themselves,
>>>> recent
>>>> > email dialog indicates that sometimes the font file simply
>>>> overrides the
>>>> > family field...
>>>> > - We do not want to change any defined functionality for *family*
>>>> and *style
>>>> > *fields, they still seem correct in X3D Architecture and no
>>>> suitable
>>>> > changes yet seen.
>>>> > - No need for *enabled *field.
>>>> >
>>>> > Our current opinion is that FontLibrary provides a superior approach
>>>> to
>>>> > continued growth of FontStyle node. To facilitate comparison and
>>>> review,
>>>> > current draft has proposed FontLibrary prose in yellow, and alternate
>>>> > (not accepted) FontStyle alternative in cyan.
>>>> >
>>>> > - X3D 4.1 (draft) Architecture, clause 15 Text component, 15.4.1
>>>> > FontLibrary
>>>> > -
>>>> >
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#FontLibrary
>>>> > X3D Architecture 4.1 draft ? ISO/IEC 19775-1:202x ? 15 Text
>>>> component
>>>> > <
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#FontLibrary
>>>> >
>>>> > 15.2.2.4 Language. The language field specifies the context of the
>>>> > language for the text string in the form of a language and a
>>>> country in
>>>> > which that language is used. Both the language and the country are
>>>> > specified using the language tags defined in which may specify
>>>> only a
>>>> > country (using the three-character codes defined in ISO 3166) or
>>>> both a
>>>> > language (using the two-character codes ...
>>>> > www.web3d.org
>>>> >
>>>> >
>>>> > Additional questions to ponder, further insights welcome:
>>>> >
>>>> > - Our impression of the term 'webfont' is that it is simply a
>>>> generic
>>>> > term, not a standard or specification per se, and often employed to
>>>> > reference WOFF. Is that correct?
>>>> >
>>>> > - Font files tend to be large. Might there ever be a use case
>>>> where
>>>> > an author chooses to define a font as source text in the url
>>>> field? We
>>>> > have some precedent for this in Script url and (sorta)
>>>> PixelTexture.
>>>> > Nevertheless font definitions are also convoluted and (perhaps
>>>> notoriously)
>>>> > difficult to parse. Of note is that WOFF2 specifically is
>>>> designed for
>>>> > effective binary compression. Our inclination so far is to not
>>>> describe
>>>> > (or encourage) definition of the font within an X3D model. YMMV
>>>> (though we
>>>> > doubt it). Much better authoring approach is to use any of many
>>>> conversion
>>>> > tools that might credibly update a legacy font into WOFF2.
>>>> >
>>>> > Thanks everyone for leaning forward on this, looking ahead to
>>>> continuing
>>>> > discussion.
>>>> >
>>>> > Have fun with font library collections for X3D models! ?
>>>> >
>>>> >
>>>> > all the best, Don
>>>> >
>>>> > --
>>>> >
>>>> > Don Brutzman Naval Postgraduate School, Code USW/Br
>>>> > brutzman at nps.edu
>>>> >
>>>> > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>>>> > +1.831.656.2149
>>>> >
>>>> > X3D graphics, virtual worlds, navy robotics
>>>> > https://faculty.nps.edu/brutzman
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------
>>>> > *From:* x3d-public <x3d-public-bounces at web3d.org> on behalf of
>>>> Brutzman,
>>>> > Donald (Don) (CIV) via x3d-public <x3d-public at web3d.org>
>>>> > *Sent:* Wednesday, February 26, 2025 5:39 PM
>>>> > *To:* X3D <x3d-public at web3d.org>
>>>> > *Cc:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>>>> > *Subject:* Re: [x3d-public] draft X3D 4.1 prose for font files and
>>>> > libraries
>>>> >
>>>> > Dick and I worked on suggested prose for X3D 4.1 with details
>>>> continuing
>>>> > in Mantis 1490 below.
>>>> >
>>>> > Review request:
>>>> >
>>>> > - X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle
>>>> > -
>>>> >
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle
>>>> >
>>>> > Improvements:
>>>> >
>>>> > - Include all X3DURLObject fields,
>>>> >
>>>> > SFTime [in,out] autoRefresh 0.0 [0,?)
>>>> > SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?)
>>>> > SFString [in,out] description ""
>>>> > SFBool [in,out] load TRUE
>>>> > MFString [in,out] url [] [URI]
>>>> >
>>>> > - Decided to NOT overload functionality of *family * field by
>>>> adding
>>>> > file names (sorry Holger! adjusting your implementation will
>>>> likely be
>>>> > simple in comparison)
>>>> >
>>>> > - New prose:
>>>> >
>>>> > The *url* field is optional and can refer to a relative or online
>>>> address
>>>> > for a font library that contains one or more font definitions. An
>>>> empty
>>>> > *url* list indicates that the default set of fonts provided by the
>>>> > browser are used. If present, only the first active font library
>>>> retrieved
>>>> > from the *url* list shall be used. Individual font library files can
>>>> be
>>>> > used by multiple FontStyle nodes in a scene. Each font file only
>>>> needs to
>>>> > be loaded once per session.
>>>> > X3D browsers shall support WOFF (MIME type application/x-font-woff)
>>>> (see W3C
>>>> > WOFF File Format
>>>> > <
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#W3C_WOFF
>>>> >).
>>>> > Support for the OpenType file format (MIME type
>>>> > application/x-font-opentype) (see OpenType Specification
>>>> > <
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/bibliography.html#OPENTYPE
>>>> >)
>>>> > and TrueType file format (MIME type application/x-font-truetype) (see
>>>> ISO/IEC
>>>> > 14496-22 Open Font Format
>>>> > <
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#I14496_22
>>>> >)
>>>> > is also recommended.
>>>> > Security, licensing, and copyright/usage permissions are handled via
>>>> the
>>>> > exposure of a font file itself.
>>>> > Support for the *autoRefresh*, *autoRefreshTimeLimit*, and *load*
>>>> fields is
>>>> > optional.
>>>> > More details on the *autoRefresh*, *autoRefreshTimeLimit*,
>>>> *description*,
>>>> > *load*, and *url* fields are contained in 9.2.1 URLs, URNs and URIs
>>>> > <
>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#URLs
>>>> >
>>>> > .
>>>> > Looking it over, adding more functionality to FontStyle node seems to
>>>> be
>>>> > unwise. Dick has an excellent proposal:
>>>> > TODO alternative approach: move all new functionality into a separate
>>>> > *FontLibrary* node to avoid complicating FontStyle further. This also
>>>> > offers the ability to succinctly load multiple font libraries in a
>>>> given
>>>> > scene. The expense of defining a new node for X3D is offset by clearer
>>>> > distinction between X3D 4.0 and 4.1, also simplifying model content
>>>> > significantly.
>>>> > Feedback is welcome.
>>>> > Leaving existing FontStyle implementations alone probably avoids many
>>>> > unintended side effects. First law of engineering: "If it ain't
>>>> broke,
>>>> > don't fix it."
>>>> >
>>>> > Thanks for all review. It feels like we are finally converging on a
>>>> > straightforward approach t
>>>>
>>>> Andreas Plesch
> Waltham, MA 02453
>
--
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250304/0ffe5e62/attachment-0001.html>
More information about the x3d-public
mailing list