[x3d-public] draft X3D 4.1 prose for font files and libraries

[John Carlson]

fontWeight field is possibly preferable to bold and italic fields.

John
On Tue, Mar 18, 2025 at 5:27 AM Holger Seelig via x3d-public <
x3d-public at web3d.org> 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
> , 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
> , 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
> 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
> 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://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://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://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://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
>
> 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
>
> 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
> . 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
>
> 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
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250318/b8a2082a/attachment-0001.html>