[x3d-public] draft X3D 4.1 prose for font files and libraries
Holger Seelig
holger.seelig at yahoo.de
Tue Mar 18 06:47:29 PDT 2025
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:x3d-public-bounces at web3d.org>> on behalf of Holger Seelig via x3d-public <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
>>>>>>>>>> Sent: Friday, March 7, 2025 2:42 PM
>>>>>>>>>> To: X3D <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
>>>>>>>>>> Cc: Holger Seelig <holger.seelig at yahoo.de <mailto:holger.seelig at yahoo.de>>; Andreas Plesch <andreasplesch at gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/9b15fc33/attachment-0001.html>
More information about the x3d-public
mailing list