[x3d-public] draft X3D 4.1 prose for font files and libraries
Andreas Plesch
andreasplesch at gmail.com
Tue Mar 4 05:18:39 PST 2025
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250304/d4643044/attachment-0001.html>
More information about the x3d-public
mailing list