[x3d-public] draft X3D 4.1 prose for font files and libraries
Michalis Kamburelis
michalis.kambi at gmail.com
Tue Mar 4 14:10:03 PST 2025
To make my questions about FontLibrary easier to understand, I prepared the
testcases, they are in
https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions
. They contain 4 questions in total -- 2 about Inline, 1 about searching
non-top-level , 4th about EXTERNPROTO.
You can git clone the whole repo of
https://github.com/michaliskambi/x3d-tests/ and go into subdirectory
font_library_questions to get all these files easily.
Please don't take the fact that I made theses tests as my encouragement to
pursue the FontLibrary design :)
- I'm really more and more convinced that FontLibrary is an unnecessary
complication. Given that font collections are rare (and can be supported in
simpler way), and opentype.js doesn't support them... I really think this
is an over-complicated design -- unnecessary for users, and possibly not
ever fully implementable by any browser.
- And in contrast, "FontStyle.url" seems like something totally obvious. 2
browsers already implement this, or something very close, from what I
understand. (And for my browser it is also trivial, so we have 3
implementations that confirm it's OK.) And all my 4 questions (from
https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions
) just disappear in the "FontStyle.url" version. Associating the font file
to FontStyle is explicit and obvious in this case.
Anyhow, I repeated my sentiment enough times already :), I'll let others
speak. From the spec standpoint, we need at least answers to my 4
questions, to understand the edge-case behavior.
Regards,
Michalis
wt., 4 mar 2025 o 19:08 Michalis Kamburelis <michalis.kambi at gmail.com>
napisał(a):
> Don,
>
> No worries, I will give you time then to carefully read my mail :)
>
> In AD 2 I raise some questions still unanswered ("""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?)"""). More explanation
> about Inline and EXTERNPROTO questions in previous mail in this thread.
>
> We also miss more testcases. Testcases that address my above questions,
> showing what happens in the cases I question about, would be desirable. We
> also miss example TTC, OTC, multiple-family WOFF and then testcases of X3D
> using them.
>
> As for your argument """overloading FontStyle with X3DUrlObject
> functionality is a bad idea, and do not support it. Presentation ought to
> be separate from network-loading functionality.""", I admittedly don't
> agree with it. Possibly, I don't understand where this argument is coming
> from :) We add X3DUrlObject to some presentation things, it's not a problem
> in my view. E.g. ImageTexture is X3DUrlObject, just like all other texture
> nodes, and AudioClip, and Inline... Adding X3DUrlObject to FontStyle would
> be consistent, in my view.
>
> As for implementations:
>
> - For X3DOM and X_ITE, from what I understand, implementing
> "FontStyle.url" is not a problem. I understand that X_ITE already had a
> similar functionality (just over-using FontStyle.family for URLs), and
> X3DOM already implements experimental FontStyle.url. Adding FontStyle.url
> to Castle Model Viewer/Castle Game Engine would be trivial too.
>
> - This is in contrast to FontLibrary. Andreas says """x3dom (or any
> browser) will not be able to support font collections""". Desktop Castle
> Model Viewer/Castle Game Engine... I don't know can I support it either
> (FreeType can query font collection by a known index, I don't see how to
> enumerate all fonts inside, and implement the spec would require it).
>
> Regards,
> Michalis
>
>
>
> wt., 4 mar 2025 o 16:35 Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> napisał(a):
>
>> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250304/2508cb4d/attachment-0001.html>
More information about the x3d-public
mailing list