[x3d-public] draft X3D 4.1 prose for font files and libraries
Andreas Plesch
andreasplesch at gmail.com
Sat Mar 29 08:40:26 PDT 2025
Thanks. I updated the x3d to v4.1 here:
https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/dc9111dcd106f1a69d567ceca8f52701/raw/3540c71489996f3024b13b09f2e9f6551a935228/FontLibrary_HaveFunWithX3D.x3d
https://andreasplesch.github.io/Library/Viewer/index.html?url=https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/dataurl/FontLibrary.x3d
https://andreasplesch.github.io/Library/Viewer/index.html?url=https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/question_9_reserved_name/test.x3d
https://andreasplesch.github.io/Library/Viewer/index.html?url=https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/fallbacks/test.x3d
https://andreasplesch.github.io/Library/Viewer/index.html?url=https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/question_3/font_library_search.x3d
https://andreasplesch.github.io/Library/Viewer/index.html?url=https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/question_2/inline_parent.x3d
On Sat, Mar 29, 2025 at 10:35 AM Holger Seelig <holger.seelig at yahoo.de>
wrote:
> Noticed a small issue with the examples. They should all have a version of
> at least „4.1“, because FontLibrary is first defined there.
>
> Best regards,
> Holger
>
> --
> Holger Seelig
> Leipzig, Germany
>
> holger.seelig at yahoo.de
> https://create3000.github.io/x_ite/
>
> Am 29.03.2025 um 14:04 schrieb Andreas Plesch <andreasplesch at gmail.com>:
>
> I have updated the x3dom editor to use an experimental FontLibrary
> implementation for convenient testing since it is now in a usable shape.
>
> Here are a few examples to play with:
>
>
> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/dc9111dcd106f1a69d567ceca8f52701/raw/50c1e300d7c85636b7fe499e8482f1939eb2c244/FontLibrary_HaveFunWithX3D.x3d
>
>
> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://raw.githubusercontent.com/andreasplesch/x3dom/720b0e130e755928584ef14b484f41e3c4f7024d/test/functional/font_library_questions/dataurl/FontLibrary.x3d
>
>
> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/question_9_reserved_name/test.x3d
>
>
> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/fallbacks/test.x3d
>
>
> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/question_3/font_library_search.x3d
>
>
> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/question_2/inline_parent.x3d
>
> see also:
>
> https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/
>
> https://andreasplesch.github.io/x3dom/test/functional/font_library_questions/all_questions.html
>
> I noticed differences in some web browsers since x3dom uses their css font
> rendering directly. Both Firefox and Chrome synthesize bold and italic
> styles but Chrome somehow recognizes if a font file is already bold or
> italic and then does not synthesize whereas Firefox still does and makes
> an already bold font even bolder. So that means it is safest to always use
> the default style field ("PLAIN") if a FontLibrary font family is
> referenced, in x3dom. Unless a variable font is used which includes the
> variations in one file. Variable fonts work fine and will take into account
> the style field.
>
> It may be possible to add an extension to take full advantage of css
> features. In effect, the FontLibray node will represent a CSS
> Fontface object and the FontStyle node the font css for a text.
>
> Any feedback or thoughts always welcome,
>
> Andreas
>
> On Mon, Mar 24, 2025 at 10:46 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> Thanks for suggesting spec. language to reserve these three family names.
>> I think that could work well.
>>
>> CSS in https://drafts.csswg.org/css-fonts/#family-name-syntax manages
>> equivalent reserved names by distinguishing between quoted and unquoted
>> names. Unquoted reserved names refer to a system font, quoted names always
>> to custom fonts. To me having such a distinction in X3D is too impractical
>> and not beneficial enough to justify the added specification load.
>>
>> I just had misrembered the TYPEWRITER family name. But my mistake may be
>> symptomatic of how MONOSPACE is more common now. Adding such as an alias of
>> TYPEWRITER in FontStyle would be convenient for authors and probably not
>> very involved but certainly not a priority.
>>
>> Andreas Plesch
>> Waltham, MA 02453
>>
>> On Mon, Mar 24, 2025, 1:36 AM Brutzman, Donald (Don) (CIV) <
>> brutzman at nps.edu> wrote:
>>
>>> Impressive body of work emerging! 🙂👍
>>>
>>> Regarding "I think I will add protection for SANS, SERIF and MONOSPACE
>>> as reserved names for standard fonts"
>>>
>>> The existing specification refers to SANS, SERIF and TYPEWRITER. It
>>> also provides important guidance regarding default behaviors if font
>>> families listed in the *family *field are not available.
>>>
>>>
>>> - X3D 4.1 (draft) Architecture, clause 15 Text component, 15.2.2.2
>>> Font family and style
>>> -
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#Fontfamilyandstyle
>>>
>>>
>>> So yes, I think it is important to reserve the fallback families.
>>> Perhaps we should add specification prose such as
>>>
>>>
>>> - X3D browsers shall consider SANS, SERIF, and TYPEWRITER as
>>> reserved font *family *names for fonts that cannot be replaced by
>>> another externally loaded font library.
>>>
>>>
>>> This sensible protection rises to the level of a security precaution: it
>>> is possible to consider several forms of harmful mischief (e.g. Impossibly
>>> small, scrambled characters, etc.) if a malicious font is somehow loaded.
>>> As ever, trusted content and trusted network connections are fundamentally
>>> important when authoring and sharing content on the Web.
>>>
>>> p.s. Wondering if we should add MONOSPACE as a alternate term for
>>> TYPEWRITER ? Seems plausible but... probably not, since we probably first
>>> decided on TYPEWRITER because it was an unlikely yet descriptive name for a
>>> default. For example, in the following list of fonts, you will not find a
>>> TYPEWRITER entry but will find numerous "Mono" variants and three
>>> "Monospace" variants.
>>>
>>>
>>> - Wikipedia: List of monospaced typefaces
>>> - https://en.wikipedia.org/wiki/List_of_monospaced_typefaces
>>> <https://en.wikipedia.org/wiki/List_of_monospaced_typefaces>
>>> List of monospaced typefaces - Wikipedia
>>> <https://en.wikipedia.org/wiki/List_of_monospaced_typefaces>
>>> Samples of Monospaced typefaces Typeface name Example 1 Example 2
>>> Example 3 Anonymous Pro [1]Bitstream Vera Sans Mono [2]Cascadia Code:
>>> Century Schoolbook Monospace
>>> en.wikipedia.org
>>>
>>>
>>> OTOH, also found several pages willing to share or sell "typewriter"
>>> fonts, for example
>>>
>>>
>>> - 1001 fonts, Typewriter Fonts
>>> - https://www.1001fonts.com/typewriter-fonts.html
>>> <https://www.1001fonts.com/typewriter-fonts.html>
>>> 208 Free Typewriter Fonts · 1001 Fonts
>>> <https://www.1001fonts.com/typewriter-fonts.html>
>>> These typewriter fonts look like they were written with an old
>>> mechanical typewriter.
>>> www.1001fonts.com
>>>
>>>
>>> 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:* Andreas Plesch
>>> *Sent:* Friday, March 21, 2025 9:21 PM
>>> *To:* Brutzman, Donald (Don) (CIV)
>>> *Cc:* Extensible 3D (X3D) Graphics public discussion; Holger Seelig
>>> *Subject:* Re: [x3d-public] draft X3D 4.1 prose for font files and
>>> libraries
>>>
>>>
>>> https://github.com/andreasplesch/x3dom/tree/FontLibrary/test/functional/font_library_questions
>>>
>>> now has all of Michalis' question scenes, after some fixes.
>>>
>>> They can be selected here:
>>>
>>>
>>> https://rawgit.com/andreasplesch/x3dom/refs/heads/FontLibrary/test/functional/font_library_questions/all_questions.html
>>>
>>> Some results are:
>>>
>>> Q4: The FL in parent does affect the Text in the Proto.
>>> Q6: If FL names are duplicated, the last one wins. All FL fonts are
>>> actually loaded but only the last one can be found by name.
>>> Q8: FontStyle.style is ignored for FL fonts. The BOLD style does not
>>> make the bold FL font even bolder by synthesis which I thought possible.
>>>
>>> Generally, the effect of FL is very global, without probably any
>>> restriction in scope, up or down level. Ordering is only important for
>>> name collision resolution.
>>>
>>> This is kind of the 'natural' outcome of the x3dom way of rendering
>>> fonts with the help of the web browser css font rendering.
>>>
>>> I think I will add protection for SANS, SERIF and MONOSPACE as reserved
>>> names for standard fonts.
>>>
>>> Is that protection something the standard would want to include ? In my
>>> view, yes, to have safe fonts for authors to use.
>>>
>>> Cheers, -Andreas
>>>
>>> On Fri, Mar 21, 2025 at 12:34 AM Andreas Plesch <andreasplesch at gmail.com>
>>> wrote:
>>>
>>> I started to translate Michalis very helpful question scenes to xml here:
>>>
>>>
>>> https://github.com/andreasplesch/x3dom/tree/FontLibrary/test/functional/font_library_questions
>>>
>>> They already discovered an issue for relative urls which needed a fix.
>>> x3dom's interpretation for the first three can be seen here:
>>>
>>>
>>> https://rawgit.com/andreasplesch/x3dom/refs/heads/FontLibrary/test/functional/font_library_questions/all_questions.html
>>>
>>> As suspected FontLibraries from anywhere are seen everywhere although I
>>> noticed that rarely and unreproducibly for question 1 the rendered font
>>> seems sans italic and not bold.
>>> Loaded fonts are supposed to be cleared from the web page each time the
>>> scene changes.
>>>
>>> Another useful Inline question may be what happens if the same family
>>> name is used for two different fonts in parent scene and child inline. I
>>> suspect for x3dom the first one found wins, eg. is used everywhere.
>>>
>>> Another question is a scene which tests if the three standard family
>>> names SANS, SERIF and MONOSPACE are protected and cannot be used for
>>> FontLibrary.family. I think these should be protected to have safe
>>> fallbacks and also a baseline which cannot be changed by and in Inlines.
>>>
>>> I will slowly work through the remaining question scenes.
>>>
>>> -Andreas
>>>
>>> On Thu, Mar 20, 2025 at 12:26 AM Andreas Plesch <andreasplesch at gmail.com>
>>> wrote:
>>>
>>> For a first cut of FontLibrary on an experimental x3dom branch, here are
>>> test scenes:
>>>
>>>
>>> https://rawgit.com/andreasplesch/x3dom/refs/heads/FontLibrary/test/functional/fonts.html (ctrl-u
>>> for code).
>>>
>>> The first one uses a new FontLibrary node implementation. The other ones
>>> use fonts defined with CSS on the html page, in X3D, which was the
>>> traditional x3dom way. Perhaps it will be possible to support more css
>>> options (see html context2d.font) with a SFString css-font field for
>>> FontStyle which could be expressed as Metadata in x3dom as well (all fields
>>> can).
>>>
>>> It turns out that with the design, variable fonts can be used as well,
>>> meaning only one font file is necessary for all styles (supported by the
>>> font).
>>> In fact, I found out that font synthesis for non-variable fonts cannot
>>> be turned off in case of rendering fonts on a html canvas, in contrast to
>>> regular html font rendering.
>>>
>>> Unfortunately, that means that x3dom will have to support font
>>> synthesis, which will make it deviate from other x3d browsers. Eg. it will
>>> be possible to use FontStyle.style=italic with a plain font file in
>>> FontLibrary.url. The synthesis will not be smart enough to go the reverse
>>> way.
>>>
>>> It also turns out in first testing that the FontLibrary node can occur
>>> in the X3D after the FontStyle node because css font loading in html is
>>> async anyways,
>>>
>>> Next will be checking how Inlines behave. ( I think as if they are just
>>> included in the parent x3d scene, without separation either way, eg. the
>>> parent can see the Inline FontLibraries, and the Inline can see the parent
>>> FontLibraries. This is due to how all fonts are registered to the html
>>> document rather than the execution context. Not sure if it will be possible
>>> to change that, perhaps with name scope prefixes for font family names.)
>>>
>>> Cheers, -Andreas
>>>
>>> On Tue, Mar 18, 2025 at 12:00 PM Brutzman, Donald (Don) (CIV) <
>>> brutzman at nps.edu> wrote:
>>>
>>> Agreed that the *family *field is sufficient for author
>>> indicating/identifying which font is being applied.
>>>
>>>
>>> - Available via identifying SFString *family *label for each
>>> individual FontLibrary font file, and
>>> - Preferred via FontStyle SFString ordered list of author-preferred *family
>>> *values.
>>>
>>>
>>> Meanwhile, FontStyle node is place where *style *information preferred
>>> by scene author remains defined.
>>>
>>>
>>> - With understanding that not all style options are necessarily
>>> supported by all font-file definitions.
>>>
>>>
>>> We can go very far with this basis. If something else is needed for
>>> style information, such that an author needs to add further information for
>>> either of these nodes, then our experimentation with implemented examples
>>> will reveal whether such a gap can be handled or not by the browser.
>>>
>>>
>>> - Extensibility bonus capability for an X3D scene: extra
>>> information can always be captured in a contained MetadataString node if
>>> browsers want to experiment with further customization.
>>> - Indeed a contained MetadataString might even provide CSS code for
>>> use in adapting a font.
>>>
>>>
>>> As with CSS, no doubt some corresponding best practices will emerge for
>>> X3D. It will be fun to see possible uses when we build a growing set of
>>> examples! 🙂
>>>
>>> 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:* Tuesday, March 18, 2025 6:47 AM
>>> *To:* Andreas Plesch <andreasplesch at gmail.com>
>>> *Cc:* Holger Seelig <holger.seelig at yahoo.de>; X3D <x3d-public at web3d.org>
>>> *Subject:* Re: [x3d-public] draft X3D 4.1 prose for font files and
>>> libraries
>>>
>>> CSS also has the concept of default values. If you don’t specify a CSS
>>> property like font-weight, the default value is used.
>>>
>>> Best regards,
>>> Holger
>>>
>>> --
>>> Holger Seelig
>>> Leipzig, Germany
>>>
>>> holger.seelig at yahoo.de
>>> https://create3000.github.io/x_ite/
>>>
>>> Am 18.03.2025 um 13:10 schrieb Andreas Plesch <andreasplesch at gmail.com>:
>>>
>>> But see
>>> https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face#examples
>>>
>>> @font-face {
>>> font-family: "Bitstream Vera Serif Bold";
>>> src: url("https://mdn.github.io/shared-assets/fonts/VeraSeBd.ttf");
>>> }
>>>
>>> body {
>>> font-family: "Bitstream Vera Serif Bold", serif;
>>> }
>>>
>>>
>>> The font-style or font-weight properties are not necessary in css for
>>> custom font faces. They are optional and only used for searching if the css
>>> font selector includes such information in addition to font-family which is
>>> required.
>>>
>>> For simplicity, I would still prefer to only rely on family. Introducing
>>> a FontLibrary. style field may not be necessary.
>>>
>>> Andreas Plesch
>>> Waltham, MA 02453
>>>
>>> On Tue, Mar 18, 2025, 6:26 AM Holger Seelig <holger.seelig at yahoo.de>
>>> wrote:
>>>
>>> I would like to say explicitly that a CSS property such as font-style or
>>> font-weight is important and must be specified in @font.-face and then
>>> later when the font is used, because this has already been incorrectly
>>> shown differently here.
>>>
>>> Best regards,
>>> Holger
>>>
>>> --
>>> Holger Seelig
>>> Leipzig, Germany
>>>
>>> holger.seelig at yahoo.de
>>> https://create3000.github.io/x_ite/
>>>
>>> Am 18.03.2025 um 10:22 schrieb Holger Seelig via x3d-public <
>>> x3d-public at web3d.org>:
>>>
>>> CSS has a similar approach with @font-face. You can specify there what
>>> font-weight, font-style and more your font from a URL is.
>>>
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face#specifying_local_font_alternatives
>>>
>>> @font-face {
>>> font-family: "MyHelvetica";
>>> src:
>>> local("Helvetica Neue Bold"), local("HelveticaNeue-Bold"),
>>> url("MgOpenModernaBold.ttf");
>>> font-weight: bold;
>>> }
>>>
>>> Later you will use this font with:
>>>
>>> .foo-class {
>>> font-family: MyHelvetica,
>>> font-weight: bold;
>>> }
>>>
>>> Best regards,
>>> Holger
>>>
>>> --
>>> Holger Seelig
>>> Leipzig, Germany
>>>
>>> holger.seelig at yahoo.de
>>> https://create3000.github.io/x_ite/
>>>
>>> Am 18.03.2025 um 08:03 schrieb Michalis Kamburelis <
>>> michalis.kambi at gmail.com>:
>>>
>>> Andreas,
>>>
>>> Ah, yes, I understand. If you don't inspect font file metadata in
>>> X3DOM, then you can only match using the (explicitly given)
>>> FontLibrary.family.
>>>
>>> This means that if one has a family with 4 styles (regular, bold,
>>> italic, bold italic), then one must create 4 separate FontLibrary
>>> nodes, each with a different family name. E.g.
>>>
>>> """
>>> FontLibrary { url "DejaVuSans-Bold.ttf" family "DejaVuSans-Bold" }
>>> FontLibrary { url "DejaVuSans-BoldOblique.ttf" family
>>> "DejaVuSans-BoldOblique" }
>>> FontLibrary { url "DejaVuSans-Oblique.ttf" family "DejaVuSans-Oblique" }
>>> FontLibrary { url "DejaVuSans.ttf" family "DejaVuSans" }
>>>
>>> Shape {
>>> geometry Text {
>>> string "Hello"
>>> fontStyle FontStyle {
>>> family "DejaVuSans-BoldOblique"
>>> style "PLAIN" # <--- this is ignored for searching in FontLibrary
>>> by X3DOM
>>> }
>>> }
>>> }
>>> """
>>>
>>> I think it's different outcome than CSS, at least looking at that
>>> example CSS on
>>> https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website
>>> . It defines family with 1 name, "myfont", and 4 styles from 4 WOFF
>>> files.
>>>
>>> Proposal:
>>>
>>> Add FontLibrary field that allows to explicitly specify the style of
>>> the font in "FontLibrary.url". Just like we already have
>>> "FontLibrary.family" that allows to explicitly specify the family
>>> name. It will allow X3DOM to make searching using family+style, it
>>> means FontStyle.style remains useful for custom fonts, and it's
>>> consistent with that CSS example linked above.
>>>
>>> Like FontLibrary {
>>> SFString [in,out] style "" ["PLAIN"|"BOLD"|"ITALIC"|"BOLDITALIC"|""]
>>> # "" is default, it means one must look at font metadata; browsers
>>> that cannot may assume PLAIN
>>> }
>>>
>>> Then one can use the same family name for all styles of the font, and
>>> then FontStyle.style still matters, in all browsers:
>>>
>>> """
>>> FontLibrary { url "DejaVuSans-Bold.ttf" family "DejaVuSans" style "BOLD"
>>> }
>>> FontLibrary { url "DejaVuSans-BoldOblique.ttf" family "DejaVuSans"
>>> style "BOLDITALIC" }
>>> FontLibrary { url "DejaVuSans-Oblique.ttf" family "DejaVuSans" style
>>> "ITALIC" }
>>> FontLibrary { url "DejaVuSans.ttf" family "DejaVuSans" style "PLAIN" }
>>>
>>> Shape {
>>> geometry Text {
>>> string "Hello"
>>> fontStyle FontStyle {
>>> family "DejaVuSans"
>>> style "BOLDITALIC" # <--- now it matters, chooses
>>> DejaVuSans-BoldOblique.ttf
>>> }
>>> }
>>> }
>>> """
>>>
>>> What does everyone think?
>>>
>>> Regards,
>>> Michalis
>>>
>>> pon., 17 mar 2025 o 21:57 Andreas Plesch <andreasplesch at gmail.com>
>>> napisał(a):
>>>
>>>
>>> My 2 cents:
>>>
>>> On Mon, Mar 17, 2025 at 3:25 PM Michalis Kamburelis <
>>> michalis.kambi at gmail.com> wrote:
>>>
>>>
>>> ...
>>> As for 3.3 (searching): Your answer doesn't account for the new
>>> searching necessitated for custom fonts.
>>>
>>> Yes, FontStyle.family has a fallback mechanism.
>>>
>>> But the new FontLibrary, and providing custom fonts, means that
>>> style (plain,italic,bold,both) also plays a role in searching. As we
>>> shown in this thread, the common case is that people have separate
>>> TTF/OTF files with 4 or less different styles. If they provide only
>>> one style (e.g. only the "italic" version) then we have a question
>>> what should the browser do when user requests an existing family name
>>> but with a "bold" (and not italic) style.
>>>
>>> See also the testcase in
>>>
>>> https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_8_unmatched_style
>>> . I show there multiple FontLibrary with separate TTF files. The same
>>> problem would arise with a font collection (like TTC) that has only
>>> some styles.
>>>
>>>
>>>
>>> I would vote for ignoring the style field completely for searching in
>>> this case, eg. when a FontLibrary.family name is matching exactly. The
>>> fallback family would be only used if there is no match or if the
>>> associated url can not be loaded. The author can easily provide multiple
>>> fonts with more specific names, say "custom font bold oblique" and "custom
>>> font bold" . I agree that "family" is then not quite the right name for the
>>> field but CSS also (ab)uses the "font-family" property in the same way
>>> (except for variable fonts) and we cannot introduce another field to
>>> FontStyle.
>>> So the test case would use the same custom font for both Shapes,
>>> ignoring the style field values.
>>> I am optimistic that this can be concisely expressed in the spec.
>>> language with a few words.
>>> As indicated x3dom would completely rely on matching family names, and
>>> probably never look into the file metadata, also following CSS.
>>>
>>>
>>> - That said, I recognize you don't want to go with FontStyle.url and
>>> we both now repeated similar arguments in this regard. If others are
>>> OK with FontLibrary, let's go with FontLibrary, I'll drop proposing
>>> FontStyle.url. Let's just address the remaining issues of FontLibrary
>>> (the sentence in 3.1, and answering new testcases on
>>>
>>> https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions
>>> ).
>>>
>>>
>>>
>>> I would have preferred a SFNode Text.fontLibray field which would enable
>>> FontLibray DEF/USE addressing duplication with the normal X3D mechanism and
>>> would solve matching (not needed anymore) and scoping (same as other nodes,
>>> EXPORT/IMPORT). I also note that a global FontLibrary implementing
>>> X3DUrlObject is as complicated as a FontLibray implementing X3DUrlObject as
>>> a field value.
>>> Unfortunately, I just cannot see the attraction of deviating from
>>> established practice but it seems designers infer enough advantages.
>>>
>>> I have some idea of how to implement FontLibray as a root node in x3dom,
>>> probably first without separation of Inline or ProtoInstance FontLibraries,
>>> and perhaps requiring FontLibray to be parsed before a matching FontStyle
>>> can use it.
>>>
>>> Cheers,
>>>
>>> Andreas
>>>
>>> pon., 17 mar 2025 o 19:08 Brutzman, Donald (Don) (CIV)
>>> <brutzman at nps.edu> napisał(a):
>>>
>>>
>>> Thanks for your note Michalis.
>>>
>>> Better than "According to Don" or "Spec Decision" (neither of which is
>>> accurate) you might use phrases like Specification Discussion (linking to
>>> the specific email url) or "Current Draft Specification" copying a quote.
>>>
>>> That 2025-03-07 email clearly indicates it was written and sent
>>> following a specification editors meeting.
>>> To be clear, thanks to continuing group dialog, some of our continuing
>>> improvement is now different than some of the responses provided in the
>>> 2025-03-07 email which Dick and I prepared and sent.
>>>
>>>
>>> My hope is that having an evolving draft document for X3D 4.1, with
>>> notes of issues & evaluations, helps us keep our email discussions focused
>>> towards achieving progress and insight, rather than our occupational hazard
>>> of way-too-long threads that provide many excellent ideas but don't
>>> necessarily get us closer to clarity.
>>>
>>> Dick and I have two meetings during the week and will look at better
>>> ways of expressing issues in the draft. We will review these responses
>>> together. For now, I can say that:
>>>
>>> For point 3.1, last week's (and still current) draft-design spec says
>>>
>>> "The visibility of FontLibrary fonts is scoped to the current model, and
>>> FontLibrary nodes are typically defined with other root nodes in a scene.
>>> Fonts from FontLibrary nodes are also usable when defined within an Inline
>>> node, or when defined among the topmost nodes of a Prototype instance
>>> contained in a scene."
>>>
>>> These two sentences are attempting to crisply define scene scope. If
>>> fonts are defined in the constructs of a scene, then naturally that same
>>> scene should see them. Scene-scope visibility is not the same as a child
>>> scene has access to the fonts defined in a parent. Likely we should add a
>>> sentence to that effect to avoid possible misunderstanding... So we will
>>> work on your point 3.1. Perhaps helpful:
>>>
>>> (rough draft) NOTE. A child scene does not have direct visibility into
>>> fonts defined within a parent scene. Meanwhile, if desired, utilizing an
>>> X3D Inline model (or external prototype) that contains multiple FontLibrary
>>> fonts is a good way for many different X3D scenes to share a consistent set
>>> of fonts.
>>>
>>>
>>> For point 3.2, more test cases are always good. However they do not
>>> have to all go in the specification, which needs to be clear and concise
>>> regarding fundamental requirements. Pursuing each of your test cases is
>>> good - but please not in the specification.
>>> We think that the current specification has become sufficient to pursue
>>> further test cases.
>>>
>>> In pursuit of test cases, I recommend starting with form shown in
>>> EXAMPLE 1. Avoid EXAMPLE 2 form.
>>> When we hit edge cases or omissions, we should next look at how
>>> HTML5/CSS handles similar cases and consider whether their approach can
>>> help.
>>> If/when specification gaps or ambiguities are revealed by the test
>>> cases, that is the time when we refine the specification.
>>>
>>>
>>> For your point 3.3, the X3D Architecture specification is clear already
>>> on what to do when a requested font is not found. We have not seen
>>> anything to improve there, the functionality for falling back to
>>> alternate-chose fonts seems satisfactory.
>>>
>>> X3D 4.1 (Draft) Architecture, clause 15 Text component, 15.2.2.2 Font
>>> family and style, excerpt:
>>>
>>> "Any font family may be specified as shown in the following example of
>>> the specification of a font family:
>>>
>>> ["Lucida Sans Typewriter", "Lucida Sans", "Helvetica", "SANS"]
>>>
>>> In this example, the X3D browser would first look for the font family
>>> "Lucida Sans Typewriter" on the system on which the X3D browser is
>>> operating. If that is not available, the X3D browser looks for "Lucida
>>> Sans". If that is not available, the browser looks for "Helvetica". If that
>>> is not available, the X3D browser looks for any sans-serif font. If there
>>> are not sans-serif fonts installed, the X3D browser will use any serif font
>>> (the default). It is the responsibility of the author that a suitable list
>>> of font families be specified so that the desired appearance is achieved in
>>> most operating environments. However, the author should always be willing
>>> to accept that the requested font families may not be available resulting
>>> in the use of a X3D browser-selected "SERIF" font being used."
>>>
>>>
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#Fontfamilyandstyle
>>>
>>>
>>> For your point 3.4, root node definition was already accepted (with
>>> thanks) and addressed by the following changes.
>>>
>>> X3D 4.1 (Draft) Architecture, clause 4 Concepts, 4.3.2 Root nodes
>>>
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#Rootnodes
>>> X3D 4.1 (Draft) Architecture, clause 4 Concepts, Figure 4.2 — Interface
>>> hierarchy (FontLibrary)
>>>
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#f-Objecthierarchy
>>>
>>>
>>> For your point 3.5,
>>>
>>> the EXAMPLE 2 prose and editors notes certainly acknowledge that the use
>>> of FontStyle.fontLibrary can work, but it is a lot more work by the author
>>> to get DEF/USE correct and no longer simple to change preferred family
>>> field. We think it is an unnecessary alternative.
>>> Perhaps we should add in notes that FontStyle.url is nearly equivalent
>>> to FontStyle.fontLibrary but is even more work by authors to get correct,
>>> repeating a often-lengthy url list every time a font is needed. All of
>>> that burden on authors is very error prone. The top-level FontLibrary node
>>> honors the Don't Repeat Yourself (DRY) design principle, is terser for the
>>> one-time operation of making a new font available, and simply avoids very
>>> many possible authoring errors and difficulties.
>>> For separation of concerns, we do understand that ImageTexture, Inline,
>>> AudioClip etc. have url field included (via X3DUrlObject interface).
>>> However, please notice that loading a unique media asset is actually the
>>> fundamental functionality of these nodes. These nodes have little other
>>> functionality beyond loading a media asset, and also can be used repeatably
>>> via DEF/USE to good effect. FontStyle has much other functionality, has
>>> numerous legacy implementations that would be suddenly incorrect in X3D
>>> 4.1, and an author wants to create multiple
>>> similar-and-related-but-different Fontstyle nodes that depend on either
>>> fontLibrary or url fields, it is a ton of work. Such a FontStyle cannot be
>>> DEF/USEd to adjust the style of a given font (indeed its original and
>>> existing purpose). Thus we want to avoid serious complications and leave
>>> FontStyle unchanged.
>>> Unlike ImageTexture, Inline, AudioClip etc. we do not see a common use
>>> case that requires potential reloading of font files - fonts change rarely.
>>> Nevertheless FontLibrary X3DUrlObject fields als supports that reload
>>> possibility if desired by the author.
>>> FontLibrary usage of SFString family field complements existing
>>> FontStyle functionality, gives authors control of naming that is
>>> independent of (or perhaps complementary to) metadata within a font file,
>>> and has several similarities to the HTML5/CSS approach. It provides
>>> greatest functionality with most concise approach. It also makes
>>> FontStyle.fontLibrary field superfluous, and thus changes to FontStyle
>>> become unnecessary.
>>> FontLibrary nodes sprinkled throughout a scene as X3DChildNode adds no
>>> value if they have scene scope. Thus keeping FontLibrary nodes at the top
>>> as root nodes makes sense, with possible additions (as described in draft
>>> spec prose) that an Inline or external ProtoInstance can also provide
>>> scene-scoped fonts to that parent scene if they contain root-node
>>> FontLibrary nodes .
>>>
>>>
>>> Hope this helps. For coming weeks, I do not expect to be able to afford
>>> much more time to repeatedly keep going into this kind of detail. Please
>>> do consider joining us for a weekly teleconference. If our regular Friday
>>> time does not work for you, please propose alternate time windows to Dick
>>> and I.
>>>
>>> Onward we go. Again thanks for your many efforts with X3D.
>>>
>>>
>>> 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
>>> Sent: Monday, March 17, 2025 4:02 AM
>>> To: Brutzman, Donald (Don) (CIV)
>>> Cc: Andreas Plesch; X3D; Holger Seelig
>>> Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and
>>> libraries
>>>
>>> Hi Don,
>>>
>>> 1. First of all, much apologies if some of my messaging appeared
>>> personal. This was not my intention.
>>>
>>> I perfectly recognize that we all work on reaching consensus and
>>> the best specification. I disagree with you, in this particular
>>> thread, on the technical choice ("what is the optimal spec to allow
>>> users to customize fonts"), but I absolutely recognize we all work
>>> towards the same goal, having a good X3D spec, consistent,
>>> implementable, useful for users.
>>>
>>> We do agree in 100 other topics around X3D, and I'm sure in the
>>> future we will agree on 100 more (and disagree on some too!). Our
>>> technical discussion doesn't change in any way my respect for your
>>> work and recognition that we try to make X3D better.
>>>
>>> 2. To be clear, when I wrote "Answer from Don" on
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_1&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898599249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MLY8roX0NWrkmLKGtKLVtPiU3TAJ5XnrgMb6X35fhUw%3D&reserved=0
>>> <https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_1>
>>> , I meant it literally. I quote precisely your email there, so I
>>> wanted to say where this text comes from. I had no other intention
>>> behind this statement, I just signaled that I literally quote your
>>> mail. I changed it now to say "Spec Decision" and link to your mail,
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Fcommit%2F5cd142f972158450b16c10d95fbbc2985b4f793d&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898622964%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8AAKciDTQKtSJNHNdAzGdmgUh9vV%2BoEU0%2FRbE367YjI%3D&reserved=0
>>> <https://github.com/michaliskambi/x3d-tests/commit/5cd142f972158450b16c10d95fbbc2985b4f793d>
>>> , let me know if this correction if satisfactory to you.
>>>
>>> 3. Going to the technical discussion, I recognize you continue to work
>>> on refining the spec. But various points still seem to be left
>>> unaddressed from the spec prose. I know, that's because this is a long
>>> thread, with many posts, including from me! So that's not an
>>> accusation, I just point out the need for more work. Let me recap
>>> things which I consider still not addressed:
>>>
>>> 3.1. The sentence "Fonts from FontLibrary nodes are also usable when
>>> defined within an Inline node" is confusing and possibly you meant an
>>> inverse statement, as Andreas already mentioned.
>>>
>>> From your past answers, I concluded that
>>> -
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_1&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898636392%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zGiuqSzOERkK75IpUkF1g5AlzeG9eYRdLydatYwo2fo%3D&reserved=0
>>> <https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_1>
>>> is valid,
>>> - but
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_2&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898649385%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ajcuNeRXJXBchq9fmCm9pXXygOIofHiYkZoKwpLPxCc%3D&reserved=0
>>> <https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_2>
>>> is not valid.
>>>
>>> The sentence "Fonts from FontLibrary nodes are also usable when
>>> defined within an Inline node" spec suggests the opposite.
>>>
>>> Instead of that sentence, I suggest this (it seems to me it
>>> matches your previous statements):
>>>
>>> """
>>> When using Inline to refer from one X3D file ("parent") to another
>>> X3D file ("child"), the FontLibrary nodes defined in the parent affect
>>> rendering of the children. That is, when the child X3D content refers
>>> to family names using FontStyle, the FontLibrary nodes of the parent
>>> X3D content are searched (in addition to searching the FontLibrary
>>> nodes in child). The inverse is not true: when the parent X3D content
>>> refers to family names using FontStyle, the FontLibrary nodes of the
>>> child X3D content are not searched.
>>> """
>>>
>>> This is longer, but unambiguous.
>>>
>>> 3.2. I recognize it's OK to be silent (or explicitly say "it's
>>> undefined") for some things, like duplicated family names. OK.
>>>
>>> But there are things we really need to clarify, the give X3D
>>> authors a confidence that certain things are supposed to work, in all
>>> browsers.
>>>
>>> So we really need to clarify some things. I proposed earlier to
>>> create additional testcases, Andreas provided more ideas too. I have
>>> added now 4 testcases. For each testcase, we need to know the answer,
>>> or consciously say "this is undefined, so various browsers will render
>>> it differently".
>>>
>>> See subdirectories with question 5 and up from
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898661912%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZwYi0KcfbTrmQ6ftiHY2pEgvygfWrmIfCIFuAVsLAlU%3D&reserved=0
>>> <https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/>
>>> :
>>>
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_5_order&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898673973%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BP10XZ7OnXrJMJe1EYqu7ndkMK5vIbcpYEl44FrUVUY%3D&reserved=0
>>> <https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_5_order>
>>>
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_6_order_and_duplicate_family_names&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898685385%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=f5d3DehISJ57PvkzufHEb2nmvJ4dHfs9uD9uNINl0GY%3D&reserved=0
>>> <https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_6_order_and_duplicate_family_names>
>>>
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_7_import_export&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898696901%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uNTRubmNqDDWU8Gw94PgbiJR22FFNVAPpBH9JhWx2HA%3D&reserved=0
>>> <https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_7_import_export>
>>>
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_8_unmatched_style&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898707886%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ab1jN2EbKGTJFRNF8sH4aVQCgGT94S7uJMPwO8URQmM%3D&reserved=0
>>> <https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_8_unmatched_style>
>>>
>>> 3.3. We still miss testcases of the font collections, with multiple
>>> fonts, with multiple styles. I do not have resources to look for them.
>>> It seems to me, these font files are rarely used -- but the spec talks
>>> about them, so we need to be able to test them. And test what happens
>>> when e.g. someone requests a family name with a style that isn't
>>> found.
>>>
>>> 3.4. Me and Andreas both observed that we need to extend "4.3.2 Root
>>> nodes", to explicitly allow FontLibrary as a root node. If the
>>> FontLibrary is not X3DChildNode, then it needs to be explicitly listed
>>> as "allowed root node".
>>>
>>> 3.5. As for the "separation of concerns", I already voiced how I feel
>>> this is incorrectly applied here.
>>>
>>> Other nodes, like textures (ImageTexture), Inline, AudioClip don't
>>> have (and don't need) such separation. Consequently, they don't need
>>> any additional clarification what URL is used for given
>>> texture/audio/inline, because it is explicitly stated. Consequently,
>>> then don't need all these questions and testcases.
>>>
>>> It seems that with fonts, we go into something more complicated
>>> (which creates all these questions about "what FontLibrary nodes
>>> match"). And inconsistent with existing way how spec refers to content
>>> (textures, audio, inline).
>>>
>>> Anyhow, I recognize I have repeated this statement now multiple
>>> times. We will not reach conclusions by us both repeating the same
>>> arguments :) If others find the FontLibrary workable, then I surely
>>> can accept it too. But let's please address the things mentioned
>>> above.
>>>
>>> Best regards,
>>> Michalis
>>>
>>> niedz., 16 mar 2025 o 21:21 Brutzman, Donald (Don) (CIV)
>>> <brutzman at nps.edu> napisał(a):
>>>
>>>
>>> Appreciate your point of view Michalis. Also appreciate much careful
>>> thinking by everyone.
>>>
>>> Dick and I have been reviewing everything regularly. We have been
>>> responsive throughout.
>>>
>>> This is not a battle or contest of wills. We are searching for a
>>> consensus solution balancing multiple concerns:
>>>
>>>
>>> correctness with other font specifications,
>>> consistency with existing X3D design,
>>> Implementation ability by browsers,
>>> Authoring concerns: simplicity, repeatability, scalability (X in X3D),
>>> testability, workable across all file formats and programming languages.
>>> Coherency of design in combination with HTML CSS and
>>> Simplicity when possible, to avoid a variety of problems.
>>>
>>>
>>> It again seems like some of our responses are not being heard, perhaps
>>> because conclusions by notes and prose in spec are not being acknowledged.
>>> Here are a few, motivated by your points... hard to remain concise in
>>> response.
>>>
>>> separation of concerns in design. Adding X3DURLObject to FontStyle
>>> might be literally workable (as shown in draft spec EXAMPLE 2) but it adds
>>> much different functionality to what is already one of the most complex
>>> (and perhaps inconsistently implemented) nodes. <firm>No thank you.</firm>
>>> Draft spec EXAMPLE 1 provides a workable alternative for every case we
>>> have looked at.
>>> Another design principle is Don't Repeat Yourself (DRY). We expect to
>>> strikethrough EXAMPLE 2 in our next meeting because it still appears
>>> superfluous. We will also look at this exchange and see if other points
>>> need to be added to notes.
>>>
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDon%2527t_repeat_yourself&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898720773%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vBTpPgg4%2FsOBuNVRJFhOGVw17sgv%2BpGPULW77YETyV8%3D&reserved=0
>>> <https://en.wikipedia.org/wiki/Don%27t_repeat_yourself>
>>>
>>> Holger's statements about "scene scope" are very clarifying, and are
>>> reflected/refined in last week's draft spec update in several places.
>>> Thanks Andreas for regular posts about your implementation experience too.
>>> It seems to me like functionality for several of your points is answered
>>> by last week's addition.
>>>
>>> Proposed. The visibility of FontLibrary fonts is scoped to the current
>>> model, and FontLibrary nodes are typically defined with other root nodes in
>>> a scene. Fonts from FontLibrary nodes are also usable when defined within
>>> an Inline node, or when defined among the topmost nodes of a Prototype
>>> instance contained in a scene.
>>>
>>> We are intentionally silent about some things. For example, if
>>> duplicate fonts are encountered, we do not specify recovery procedures.
>>> This is in keeping with X3D design to not require browser responses when
>>> behavior is nondeterministic and better left not defined. Of note is that
>>> such things (e.g. which font came first?) are usually preventable by
>>> authors who can carefully create correct results.
>>>
>>> If an issue is so uproarious that it must be mentioned, we might go as
>>> far as a "behavior is undefined" note. For example
>>> "NOTE. Behavior is undefined when multiple fonts are defined with the
>>> same family name."
>>>
>>>
>>> X3D Architecture 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
>>>
>>>
>>> Process concerns.
>>>
>>> Specification additions are only considered formally once work when
>>> consensus is reached. This has been the case without fail since 1995.
>>> Consensus = it works by meeting all goals, and everyone involved can
>>> live with whatever seems suboptimal to them (aka "I can live with it").
>>> Can be hard to reach, but is usually easy to tell when we aren't there.
>>> Our carefully phrased refinements did not provide responses in kind,
>>> rather you have given a long list of arguments. Does not seem very
>>> workable.
>>> Timing: there is no urgency to "reconsider" since there is no deadline
>>> whatsoever. If people want the node we will continue towards consensus.
>>> Please depersonalize your online pages. For example, "Answer from Don"
>>> is unsatisfactory. We are being scientific, taking an engineering approach.
>>> Our "editors notes" in the draft page try to complement draft spec prose
>>> with distilled goals, issues, alternatives, and choices.
>>> Once we have a baseline design to pursue, then agreed that pursuit of
>>> test-case examples is constructive and helpful.
>>>
>>>
>>> Recommendation: you and everyone involved who wants is welcome to
>>> please join one of our Friday calls to discuss. When would you like to
>>> meet and talk?
>>>
>>> Web3D Calendar, X3D Standards Editor weekly meeting
>>> Fridays 09-1000 pacific, regular Web3D zoom line
>>>
>>> https://www.web3d.org/calendar/2752/x3d-standards-editors/2025-01-10t170000-2025-01-17t170000-2025-01-24t170000-2025-01
>>>
>>> With thanks. Onward we go.
>>>
>>>
>>> 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
>>> Sent: Friday, March 14, 2025 3:39 AM
>>> To: Andreas Plesch
>>> Cc: Brutzman, Donald (Don) (CIV); X3D; Holger Seelig
>>> Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and
>>> libraries
>>>
>>>
>>> From my side:
>>>
>>> 1. I already voiced a few times that I find this "FontLibrary" design
>>> incorrect. We go into a complicated design with various edge-cases --
>>> which FontLibrary nodes are searched, in what order, and how does this
>>> searching interact with Inline, EXTERNPROTO. Oh, and IMPORT (we didn't
>>> talk about it yet). The spec doesn't answer these questions in a
>>> precise way right now.
>>>
>>> And we have technical limitations of some browsers to read the
>>> font files before they are rendered (thus extracting family name from
>>> font file contents), to support font collections, to enumerate all
>>> fonts in a font collection.
>>>
>>> This means -> the spec will not be handled consistently with all
>>> the browsers. We already know this, for sure (given technical
>>> limitations voiced in this thread). That's bad for users.
>>>
>>> I still have not heard a convincing argument why a more
>>> straightforward "FontStyle.url" was rejected. "FontStyle.url" seems
>>> like a straightforward solution that avoids all the pitfalls of
>>> "FontLibrary", because the association between FontStyle <-> font file
>>> is just explicit. All the existing X3D mechanisms (Inline,
>>> EXTERNPROTO, IMPORT, DEF/USE) have obvious application in this case.
>>>
>>> From what I can see, all the X3D browsers can support, or even
>>> support already, "FontStyle.url" in an unambiguous way. On the other
>>> side, the "FontLibrary" has a number of optional features that are
>>> already known to be impossible for some implementations, and we still
>>> have a number of open questions, not clarified by the spec, how
>>> "FontLibrary" should behave.
>>>
>>> I really ask one more time to reconsider. This long long thread is
>>> a proof in itself: we keep talking, and we keep finding more and more
>>> holes in "FontLibrary" design. Let's turn back :)
>>>
>>> 2. In case my plea from AD 1 is ignored, we at least definitely need
>>> more testcases covering the questions from AD 1. I already made some,
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898732868%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w6xIoQYFb0z9cU8cE%2BAdaVK3fYBLplJHhMCKw1wKHcQ%3D&reserved=0
>>> <https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions>
>>> . I ask people who push for this design of FontLibrary to provide more
>>> testcases.
>>>
>>> To be clear, a testcase must be a complete X3D file (not only a
>>> snippet), and it should be accompanied by a text (README file, or
>>> comment inside X3D file) describing the desired effect. It should be
>>> "complete" (so, provide also font files, and all other files
>>> referenced by Inline, EXTERNPROTO). The idea is that browser
>>> implementors can open the testcase, and trivially conclude "my
>>> behavior is correct / incorrect".
>>>
>>> Some things that need to be covered by testcases:
>>>
>>> - Clarify order: X3D file with FontLibrary node A, than shape B
>>> using a font, then another FontLibrary C. Show unambiguously whether
>>> interpreting B is affected by C or not. In case A and C define the
>>> same family names.
>>>
>>> - Show the case of IMPORTing a FontLibrary from Inline. I guess
>>> the IMPORTed FontLibrary node should be searched, as if it was part of
>>> the top-level file?
>>>
>>> - Testcases of the font collections, with multiple fonts, with
>>> multiple styles.
>>>
>>> - Show what happens when a font family is found within some
>>> FontLibrary, but not with a matching style. Do not leave it in the
>>> spec undefined. Remember that browsers in general cannot "synthesize
>>> the missing style", we agreed in this thread that this is both a
>>> difficult thing and the results have poor quality. So the spec (and
>>> testcases) should qualify what is the fallback then -- should we use
>>> another style from the same family? Should we fallback from font
>>> family "foo", style "italic" -> font family "foo", style "regular"?
>>> And the reverse, should the font family "foo", style "regular" ->
>>> fallback on "foo", style "italic" (if only the latter is available)?
>>> Or should it fallback on the browser default font?
>>>
>>> Regards,
>>> Michalis
>>>
>>> czw., 13 mar 2025 o 23:16 Andreas Plesch <andreasplesch at gmail.com>
>>> napisał(a):
>>>
>>>
>>> Thanks for further careful consideration and adjustments. Hopefully, it
>>> is not too late to add to the discussion further.
>>>
>>> If support of font collection files which contain multiple fonts is
>>> required for full compliance, it will be important to a) show a concrete
>>> test case perhaps with an Asian font which implementations can target and
>>> b) fully define how the selection of the desired font out of the multiple
>>> fonts in the file should be accomplished, eg. perhaps by an indexed order
>>> in the file, or by one of the font family names ("full name") in the
>>> metadata, or by another mechanism like fuzzy matching.
>>>
>>> Thus, please consider that support for font collections is explicitly
>>> made optional, or only guaranteed at a higher component level.
>>>
>>> Second, in summary of the below, let me also suggest that font names,
>>> sourced from the family field or from metadata, become name scoped to allow
>>> for separation of Inlines, and ProtoInstances.
>>>
>>> Third, is ordering important ? Can a FontStyle node only occur after a
>>> FontLibray node it references (similar to USE after DEF) ?
>>>
>>> Fuller discussion:
>>>
>>> With the emphasis of the FontLibray.family field over the optional
>>> lookup of a font family name in the metadata of the font file, a global
>>> scope of FontLibray is more attractive. The way the global scope is
>>> intended to be clearly expressed may not quite succeed:
>>>
>>> "Fonts from FontLibrary nodes are also usable when defined within an
>>> Inline node"
>>>
>>> probably means that if an Inline node has a font defined in a
>>> FontLibrary root node within it, it is usable also in the parent node. But
>>> I think this is the opposite of the iframe case, so the sentence may
>>> actually mean the opposite ?
>>>
>>> In any case, the way x3dom would probably handle a global/model wide
>>> FontLibrary scope is in two steps. First, whenever a FontLibrary node is
>>> encountered, register/add the defined font to the master document/model.
>>> This would be true even if encountered in an Inline or ProtoInstance. Then,
>>> when a FontStyle references the font by a matching family name, load the
>>> font which may or may not include downloading and then use it for
>>> rendering. This would be also true any time and even if encountered in an
>>> Inline or ProtoInstance.
>>>
>>> This has the effect that the order in which FontLibrary nodes are
>>> encountered is important. I think the order would probably play a role in
>>> any scenario. In addition this procedure also means that font family names
>>> would probably be name scoped to prevent leaking, similar to DEF/USE names.
>>> A font family name then can only be used for matching within the same name
>>> scope, eg. names can never match across name scopes.
>>>
>>> So a parent could not impact a child's font handling and vice versa.
>>> This complete separation would closely resemble the iframe separation which
>>> occurs also in both directions.
>>>
>>> Finally, I still have my doubts that these are not complications which
>>> only appear to be a simpler and more elegant match for font resource
>>> handling but are actually harder to understand and ultimately unnecessary.
>>>
>>> Any feedback or thoughts appreciated,
>>>
>>> Andreas Plesch
>>> Waltham, MA 02453
>>>
>>> On Thu, Mar 13, 2025, 1:12 PM Brutzman, Donald (Don) (CIV) <
>>> brutzman at nps.edu> wrote:
>>>
>>>
>>> Holger, thanks for these carefully expressed points, very convincing.
>>> Also thanks to others for steadily progressing dialog on this topic.
>>>
>>> Dick and I met yesterday and looked closely at how to express "scene
>>> scope" satisfactorily.
>>>
>>> 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
>>>
>>>
>>> Summary of latest revision follows. (color-code reminder: yellow is
>>> proposed, cyan is editors note)
>>>
>>> FontLibrary family field is an important addition that resolves several
>>> challenges, we are ready to accept it.
>>>
>>> Current node 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 and ScreenFontStyle nodes.
>>>
>>>
>>> Proposed addition:
>>>
>>> The visibility of FontLibrary fonts is scoped to the current model, and
>>> FontLibrary nodes are typically defined with other root nodes in a scene.
>>> Fonts from FontLibrary nodes are also usable when defined within an Inline
>>> node, or when defined among the topmost nodes of a Prototype instance
>>> contained in a scene.
>>>
>>>
>>> Keeping track of design rationale, we combined several thoughts as
>>> follows.
>>>
>>> Editors note: key questions are
>>>
>>> Whether global scope is needed for FontLibrary fonts, rather than just
>>> within a FontStyle node; we think yes, fonts ought to have scene scope for
>>> the current model.
>>> If fonts are visible throughout a given model, then scoping a
>>> FontLibrary node within a FontStyle fontLibrary field appears to be
>>> superfluous. This avoids much unnecessary complication, especially if an
>>> author simply wants to change the value of a FontStyle family field.
>>> Whether a single font file contains more than one font; yes, various
>>> specifications indicate that may occur for some font files.
>>> Whether a browser might look inside the font file to check internal
>>> metadata and find one of multiple family names; yes that option seems like
>>> a good idea if no common matching family field is found for the FontStyle
>>> and FontLibrary nodes.
>>>
>>>
>>> Subject to group scrutiny and discussion, we are ready to
>>>
>>>
>>> Remove Example 2
>>>
>>> Editors note: the fontLibrary fields shown in EXAMPLE 2 appear to be an
>>> unnecessary complication, since the approach shown in Example 1 can also
>>> work for each of these two scene fragments. Subject to mailing list
>>> discussion, we expect to delete both fragments in EXAMPLE 2.
>>>
>>>
>>> Remove the corresponding FontStyle fontLibrary field in 15.4.2 FontStyle
>>>
>>>
>>> Hopefully we haven't overlooked reconciliation of any of the many prior
>>> discussion points. Continued scrutiny and discussion remain welcome.
>>>
>>> Feels like we are getting close to an excellent design balance.
>>> Hopefully others feel that way too.
>>>
>>> Have fun with fonts in X3D! 🙂
>>>
>>>
>>> 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: Friday, March 7, 2025 2:42 PM
>>> To: X3D <x3d-public at web3d.org>
>>> Cc: Holger Seelig <holger.seelig at yahoo.de>; Andreas Plesch <
>>> andreasplesch at gmail.com>
>>> Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and
>>> libraries
>>>
>>> I think a FontLibrary should be scene scoped and no more. An Inline
>>> scene should not have access to the parent scenes FontLibrary nodes
>>> registers fonts (via FontLibrary.family field).
>>>
>>> In HTML there is a iframe element, the document in this element can’t
>>> get access to the parent document, It is completely separated. One reason
>>> is that an iframe is often used for advertising which comes often from a
>>> different provider and the advertising document should not have access to
>>> the parent document for security reasons.
>>>
>>> I also think that FontStyle.fontLibrary is not necessary. It makes the
>>> code more readable if FontLibrary is a root node.
>>>
>>> Best regards,
>>> Holger
>>>
>>> --
>>> Holger Seelig
>>> Leipzig, Germany
>>>
>>> holger.seelig at yahoo.de
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898745164%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yRAaVbY3QwiJu5T9Hk16fPwRx%2BOGnyh5AgZsryyStiw%3D&reserved=0
>>> <https://create3000.github.io/x_ite/>
>>>
>>> Am 07.03.2025 um 21:13 schrieb John Carlson via x3d-public <
>>> x3d-public at web3d.org>:
>>>
>>>
>>>
>>> On Fri, Mar 7, 2025 at 1:33 PM Brutzman, Donald (Don) (CIV) via
>>> x3d-public <x3d-public at web3d.org> wrote:
>>>
>>> separation of concerns, i.e. keeping url networking separate from
>>> FontStyle presentation, not overwhelming FontStyle functionality. Thus,
>>> FontStyle.url is simply incomplete design, and FontStyle.fontLibrary is a
>>> more-correct alternative, if we want font scope limited to a single
>>> FontStyle node.
>>>
>>>
>>> I don't understand why the same argument doesn't also apply to
>>> ImageTexture. I'm not seeing ImageTexture.url networking separate from
>>> ImageTexture presentation? Do we need an ImageLibrary?
>>>
>>> John
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>
--
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250329/0aee7b8b/attachment-0001.html>
More information about the x3d-public
mailing list