[x3d-public] draft X3D 4.1 prose for font files and libraries
Andreas Plesch
andreasplesch at gmail.com
Sun Mar 23 22:11:36 PDT 2025
https://rawgit.com/andreasplesch/x3dom/refs/heads/FontLibrary/test/functional/font_library_questions/all_questions.html
has two more FontLibrary tests, nine and ten. Nine checks if TYPEWRITER can
be used as FontLibrary.family name (it cannot), and ten tests
fallback handling.
x3dom aims to handle fallbacks in this order:
First, regular url field fallback, eg. try all urls from left to right
until one loads. This is delegated to the web browser FontFace API which
has this built in.
Second, FontStyle.family fallback, eg. try all families from left to right
until one loads. If no usable family is available, use SERIF.
Then give useful info on failed loading attempts on the console (press "d").
Are there other fallback strategies ? I cannot think of any at this point.
The test has one Shape where two FontLibrary fonts are referenced but are
not accessible. The final fallback is SANS.
The second Shape also has two FontLibrary fonts but now the second one is
accessible and should be used. There is also a final SANS fallback which
should not be used.
I should add a case which tests url fallback.
-Andreas
PS:
https://rawgit.com/andreasplesch/x3dom/refs/heads/FontLibrary/test/functional/fonts.html
and
https://rawgit.com/andreasplesch/x3dom/refs/heads/FontLibrary/test/regression-suite/test/cases/text/text.html
have more font examples.
On Sat, Mar 22, 2025 at 12:21 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250324/61ad0f33/attachment-0001.html>
More information about the x3d-public
mailing list