[x3d-public] draft X3D 4.1 prose for font files and libraries
Andreas Plesch
andreasplesch at gmail.com
Tue Mar 4 08:22:54 PST 2025
Hi Don,
just a short correction. The examples would not currently work with x3dom
since there is no implementation of a FontLibrary node. Only FontStyle.url
is implemented, experimentally.
x3dom (or any browser) will not be able to support font collections, and
will require the FontLibrary.family field.
I personally do not see the advantage of having a global FontLibrary node.
Are there any advantages (apart from not having to touch FontStyle) ? There
are clear disadvantages which Michalis had laid out well.
-Andreas
On Tue, Mar 4, 2025 at 10:35 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> Thanks for careful review Michalis.
>
> Dick Puk and I met Monday (before your email) and made some refinements.
>
> - Scrapped 'enabled' field
> - Improved prose, closely reviewed Examples 1 and 2.
> - We have been carefully tracking the email threads to date, and think
> we have addressed almost all concerns.
>
> Some of our prose refinements match yours, some don't.
>
> - We really think that overloading FontStyle with X3DUrlObject
> functionality is a bad idea, and do not support it. Presentation ought to
> be separate from network-loading functionality. That overstrike-cyan
> prose has been removed.
> - As a result, each of your FontStyle.url examples remain supported by
> FontLibrary.url field.
> - Now that Example 1 (FontLibrary outside of FontStyle) and Example 2
> (FontLibrary inside of FontStyle), few advantages appear relevant for
> adding a FontStyle.fontLibrary field.
> - This addresses many of the complications that you point out.
>
> - X3D 4.1 (Draft) Architecture, clause 15.4 Node reference
> -
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#NodeReference
>
> Summary of our review:
>
> - it seems like the current two-path approach offers compatible
> alternatives, and avoiding FontStyle.fontLibrary field completely still
> works and is simpler... Thus preferred.
> - When multiple different font families exist within a single font
> file, browser inspection of name information inside that file seems
> necessary.
>
> Michalis, I will study your email further when time permits. This is a
> preliminary response describing yesterday evening's specification efforts.
>
> Just ran some more tests. Progress report: it is super impressive that
> both EXAMPLE 1 and EXAMPLE 2 run satisfactorily in both X3DOM Editor and
> X_ITE Playground... A real testament to great implementations that
> variations to expectations are supported. Standing Ovation!
>
> Further improvements are welcome, of course. However we have come a long
> way... Am hoping to avoid a spiraling email cyclone.
>
> If we are converging, great. Incidentally it does not hurt to keep both
> of these approaches and work further on examples implementations.
>
> If we are clarifying alternatives, yes please let's keep improving draft
> specification prose.
>
> If we are not converging, that is OK too... we might consider having a
> meeting to discuss with each other, to understand goals/contraints/problems
> and example use cases well. "First seek to understand" seems apropos.
>
> Onward we go... Again thanks for much excellent thinking and multiple
> great efforts.
>
>
> 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:* Michalis Kamburelis <michalis.kambi at gmail.com>
> *Sent:* Tuesday, March 4, 2025 4:43 AM
> *To:* Andreas Plesch <andreasplesch at gmail.com>
> *Cc:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; 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
>
>
> NPS WARNING: *external sender* verify before acting.
>
> 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 to valuable future capabilities.
> >
> > Have fun with X3D fonts! ?
> >
> >
> > 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:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> > *Sent:* Monday, February 24, 2025 9:32 AM
> > *To:* X3D <x3d-public at web3d.org>
> > *Cc:* Holger Seelig <holger.seelig at yahoo.de>
> > *Subject:* Re: [x3d-public] Open dyslexic and/or (unfortunately)
> > comicsans fonts; draft X3D 4.1 prose for font files and libraries
> >
> > Wow, really super Holger! ?
> >
> > There was a conversation about this on x3d-public a few years back... We
> > committed to adding it in X3D 4.1 and (if I recall correctly) also noted
> > that adding a url field might enable usage of larger font files.
> >
> > I've attempted to capture this candidate specification change in a Mantis
> > issue. All review, feedback, and improvements are always welcome.
> >
> > - Mantis 1490 FontStyle handling of font files and font libraries
> > - https://mantis.web3d.org/view.php?id=1490
> >
> > Description.
> > A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464
> > <https://mantis.web3d.org/view.php?id=1464>).
> >
> > Addition of individual-font files might be accomplished by listing the
> > font file name in the FontStyle 'family' field.
> >
> > Referencing different fonts in a single combined font library file may
> > require an additional field, for example 'url'. In general the use of a
> > font library may be preferred, but repeatedly run-time retrieval of a
> font
> > library is not desirable, since the file might be quite large and rarely
> > changing. This might be noted in the specification prose, e.g.
> >
> > - "MFString [in,out] url [] [URI]"
> > - "The family field may list a specific font file. A font listed in the
> > family field may be provided by a corresponding font library."
> > - "The url field may refer to a font library. Font libraries can be used
> > by multiple FontStyle nodes in a scene and need only be loaded once per
> > session."
> >
> > Support levels: add "Level 2, FontStyle, support for font files in family
> > field and support for font libraries via url field ."
> >
> > Security, licensing, and copyright/usage issues are handled via the
> > exposure of the font file itself. If retrievable (locally or online) then
> > proper access is presumably handled separately.
> >
> > Additional information.
> > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle
> > -
> >
> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle
> >
> > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text
> > -
> >
> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text
> >
> > - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels
> > -
> >
> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels
> >
> > Have fun with X3D Text! :)
> >
> >
> > 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 Holger
> > Seelig via x3d-public <x3d-public at web3d.org>
> > *Sent:* Monday, February 24, 2025 2:48 AM
> > *To:* X3D <x3d-public at web3d.org>
> > *Cc:* Holger Seelig <holger.seelig at yahoo.de>
> > *Subject:* Re: [x3d-public] Open dyslexic and/or (unfortunately)
> > comicsans fonts
> >
> > With X_ITE you can use a URL in the family field of a FontStyle node to
> > specify a path to a custom font file. Provided you have one of these
> fonts,
> > it should be very easy:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 4.0//EN" "
> > https://www.web3d.org/specifications/x3d-4.0.dtd">
> > <X3D profile='Interchange' version='4.0' xmlns:xsd='
> > http://www.w3.org/2001/XMLSchema-instance'
> xsd:noNamespaceSchemaLocation='
> > https://www.web3d.org/specifications/x3d-4.0.xsd'>
> > <head>
> > <component name='Text' level='1'/>
> > </head>
> > <Scene>
> > <Transform DEF='Text'>
> > <Shape>
> > <Appearance>
> > <Material/>
> > </Appearance>
> > <Text
> > string='"3D Text"'>
> > <FontStyle
> > family='"path/to/your/font.otf", "SERIF"'/>
> > </Text>
> > </Shape>
> > </Transform>
> > </Scene>
> > </X3D>
> >
> > Supported File Formats:
> >
> >
> https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats
> >
> > Best regards,
> > Holger
> >
> > --
> > Holger Seelig
> > Leipzig, Germany
> >
> > holger.seelig at yahoo.de
> > https://create3000.github.io/x_ite/
> >
> > Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public <
> > x3d-public at web3d.org>:
> >
> > If someone knows how change the fonts of the standards to OpenDyslexic or
> > ComicSans, that might be a great accessibility experiment.
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250301/db01b350/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 191, Issue 133
> ********************************************
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
>
>
> --
> 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/c5302581/attachment-0001.html>
More information about the x3d-public
mailing list