[x3d-public] draft X3D 4.1 prose for font files and libraries
Andreas Plesch
andreasplesch at gmail.com
Tue Mar 18 11:03:35 PDT 2025
Yes, good point, each property has an initial value. The full, pretty gory
details on how font matching occurs are here:
https://drafts.csswg.org/css-fonts/#font-style-matching
So, more correctly, I should have said that font-style or font-weight are
only used if font-family by itself does not produce a unique match.
If a requested font-family uniquely matches the font-family provided in a
@font-face rule, font-style or font-weight will not be further considered,
even if they have initial values.
I hope, for KISS reasons, it is possible to just have a single field, eg.
FontLibrary.family, to uniquely identify a font resource. This would be the
author's responsibility.
-Andreas
On Tue, Mar 18, 2025 at 9:47 AM Holger Seelig <holger.seelig at yahoo.de>
wrote:
> CSS also has the concept of default values. If you don’t specify a CSS
> property like font-weight, the default value is used.
>
> Best regards,
> Holger
>
> --
> Holger Seelig
> Leipzig, Germany
>
> holger.seelig at yahoo.de
> https://create3000.github.io/x_ite/
>
> Am 18.03.2025 um 13:10 schrieb Andreas Plesch <andreasplesch at gmail.com>:
>
> But see
> https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face#examples
>
> @font-face {
> font-family: "Bitstream Vera Serif Bold";
> src: url("https://mdn.github.io/shared-assets/fonts/VeraSeBd.ttf");
> }
>
> body {
> font-family: "Bitstream Vera Serif Bold", serif;
> }
>
>
> The font-style or font-weight properties are not necessary in css for
> custom font faces. They are optional and only used for searching if the css
> font selector includes such information in addition to font-family which is
> required.
>
> For simplicity, I would still prefer to only rely on family. Introducing a
> FontLibrary. style field may not be necessary.
>
> Andreas Plesch
> Waltham, MA 02453
>
> On Tue, Mar 18, 2025, 6:26 AM Holger Seelig <holger.seelig at yahoo.de>
> wrote:
>
>> I would like to say explicitly that a CSS property such as font-style or
>> font-weight is important and must be specified in @font.-face and then
>> later when the font is used, because this has already been incorrectly
>> shown differently here.
>>
>> Best regards,
>> Holger
>>
>> --
>> Holger Seelig
>> Leipzig, Germany
>>
>> holger.seelig at yahoo.de
>> https://create3000.github.io/x_ite/
>>
>> Am 18.03.2025 um 10:22 schrieb Holger Seelig via x3d-public <
>> x3d-public at web3d.org>:
>>
>> CSS has a similar approach with @font-face. You can specify there what
>> font-weight, font-style and more your font from a URL is.
>>
>>
>> https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face#specifying_local_font_alternatives
>>
>> @font-face {
>> font-family: "MyHelvetica";
>> src:
>> local("Helvetica Neue Bold"), local("HelveticaNeue-Bold"),
>> url("MgOpenModernaBold.ttf");
>> font-weight: bold;
>> }
>>
>> Later you will use this font with:
>>
>> .foo-class {
>> font-family: MyHelvetica,
>> font-weight: bold;
>> }
>>
>> Best regards,
>> Holger
>>
>> --
>> Holger Seelig
>> Leipzig, Germany
>>
>> holger.seelig at yahoo.de
>> https://create3000.github.io/x_ite/
>>
>> Am 18.03.2025 um 08:03 schrieb Michalis Kamburelis <
>> michalis.kambi at gmail.com>:
>>
>> Andreas,
>>
>> Ah, yes, I understand. If you don't inspect font file metadata in
>> X3DOM, then you can only match using the (explicitly given)
>> FontLibrary.family.
>>
>> This means that if one has a family with 4 styles (regular, bold,
>> italic, bold italic), then one must create 4 separate FontLibrary
>> nodes, each with a different family name. E.g.
>>
>> """
>> FontLibrary { url "DejaVuSans-Bold.ttf" family "DejaVuSans-Bold" }
>> FontLibrary { url "DejaVuSans-BoldOblique.ttf" family
>> "DejaVuSans-BoldOblique" }
>> FontLibrary { url "DejaVuSans-Oblique.ttf" family "DejaVuSans-Oblique" }
>> FontLibrary { url "DejaVuSans.ttf" family "DejaVuSans" }
>>
>> Shape {
>> geometry Text {
>> string "Hello"
>> fontStyle FontStyle {
>> family "DejaVuSans-BoldOblique"
>> style "PLAIN" # <--- this is ignored for searching in FontLibrary by
>> X3DOM
>> }
>> }
>> }
>> """
>>
>> I think it's different outcome than CSS, at least looking at that
>> example CSS on
>> https://stackoverflow.com/questions/12812441/how-do-i-use-woff-fonts-for-my-website
>> . It defines family with 1 name, "myfont", and 4 styles from 4 WOFF
>> files.
>>
>> Proposal:
>>
>> Add FontLibrary field that allows to explicitly specify the style of
>> the font in "FontLibrary.url". Just like we already have
>> "FontLibrary.family" that allows to explicitly specify the family
>> name. It will allow X3DOM to make searching using family+style, it
>> means FontStyle.style remains useful for custom fonts, and it's
>> consistent with that CSS example linked above.
>>
>> Like FontLibrary {
>> SFString [in,out] style "" ["PLAIN"|"BOLD"|"ITALIC"|"BOLDITALIC"|""]
>> # "" is default, it means one must look at font metadata; browsers
>> that cannot may assume PLAIN
>> }
>>
>> Then one can use the same family name for all styles of the font, and
>> then FontStyle.style still matters, in all browsers:
>>
>> """
>> FontLibrary { url "DejaVuSans-Bold.ttf" family "DejaVuSans" style "BOLD" }
>> FontLibrary { url "DejaVuSans-BoldOblique.ttf" family "DejaVuSans"
>> style "BOLDITALIC" }
>> FontLibrary { url "DejaVuSans-Oblique.ttf" family "DejaVuSans" style
>> "ITALIC" }
>> FontLibrary { url "DejaVuSans.ttf" family "DejaVuSans" style "PLAIN" }
>>
>> Shape {
>> geometry Text {
>> string "Hello"
>> fontStyle FontStyle {
>> family "DejaVuSans"
>> style "BOLDITALIC" # <--- now it matters, chooses
>> DejaVuSans-BoldOblique.ttf
>> }
>> }
>> }
>> """
>>
>> What does everyone think?
>>
>> Regards,
>> Michalis
>>
>> pon., 17 mar 2025 o 21:57 Andreas Plesch <andreasplesch at gmail.com>
>> napisał(a):
>>
>>
>> My 2 cents:
>>
>> On Mon, Mar 17, 2025 at 3:25 PM Michalis Kamburelis <
>> michalis.kambi at gmail.com> wrote:
>>
>>
>> ...
>> As for 3.3 (searching): Your answer doesn't account for the new
>> searching necessitated for custom fonts.
>>
>> Yes, FontStyle.family has a fallback mechanism.
>>
>> But the new FontLibrary, and providing custom fonts, means that
>> style (plain,italic,bold,both) also plays a role in searching. As we
>> shown in this thread, the common case is that people have separate
>> TTF/OTF files with 4 or less different styles. If they provide only
>> one style (e.g. only the "italic" version) then we have a question
>> what should the browser do when user requests an existing family name
>> but with a "bold" (and not italic) style.
>>
>> See also the testcase in
>>
>> https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_8_unmatched_style
>> . I show there multiple FontLibrary with separate TTF files. The same
>> problem would arise with a font collection (like TTC) that has only
>> some styles.
>>
>>
>>
>> I would vote for ignoring the style field completely for searching in
>> this case, eg. when a FontLibrary.family name is matching exactly. The
>> fallback family would be only used if there is no match or if the
>> associated url can not be loaded. The author can easily provide multiple
>> fonts with more specific names, say "custom font bold oblique" and "custom
>> font bold" . I agree that "family" is then not quite the right name for the
>> field but CSS also (ab)uses the "font-family" property in the same way
>> (except for variable fonts) and we cannot introduce another field to
>> FontStyle.
>> So the test case would use the same custom font for both Shapes, ignoring
>> the style field values.
>> I am optimistic that this can be concisely expressed in the spec.
>> language with a few words.
>> As indicated x3dom would completely rely on matching family names, and
>> probably never look into the file metadata, also following CSS.
>>
>>
>> - That said, I recognize you don't want to go with FontStyle.url and
>> we both now repeated similar arguments in this regard. If others are
>> OK with FontLibrary, let's go with FontLibrary, I'll drop proposing
>> FontStyle.url. Let's just address the remaining issues of FontLibrary
>> (the sentence in 3.1, and answering new testcases on
>>
>> https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions
>> ).
>>
>>
>>
>> I would have preferred a SFNode Text.fontLibray field which would enable
>> FontLibray DEF/USE addressing duplication with the normal X3D mechanism and
>> would solve matching (not needed anymore) and scoping (same as other nodes,
>> EXPORT/IMPORT). I also note that a global FontLibrary implementing
>> X3DUrlObject is as complicated as a FontLibray implementing X3DUrlObject as
>> a field value.
>> Unfortunately, I just cannot see the attraction of deviating from
>> established practice but it seems designers infer enough advantages.
>>
>> I have some idea of how to implement FontLibray as a root node in x3dom,
>> probably first without separation of Inline or ProtoInstance FontLibraries,
>> and perhaps requiring FontLibray to be parsed before a matching FontStyle
>> can use it.
>>
>> Cheers,
>>
>> Andreas
>>
>> pon., 17 mar 2025 o 19:08 Brutzman, Donald (Don) (CIV)
>> <brutzman at nps.edu> napisał(a):
>>
>>
>> Thanks for your note Michalis.
>>
>> Better than "According to Don" or "Spec Decision" (neither of which is
>> accurate) you might use phrases like Specification Discussion (linking to
>> the specific email url) or "Current Draft Specification" copying a quote.
>>
>> That 2025-03-07 email clearly indicates it was written and sent following
>> a specification editors meeting.
>> To be clear, thanks to continuing group dialog, some of our continuing
>> improvement is now different than some of the responses provided in the
>> 2025-03-07 email which Dick and I prepared and sent.
>>
>>
>> My hope is that having an evolving draft document for X3D 4.1, with notes
>> of issues & evaluations, helps us keep our email discussions focused
>> towards achieving progress and insight, rather than our occupational hazard
>> of way-too-long threads that provide many excellent ideas but don't
>> necessarily get us closer to clarity.
>>
>> Dick and I have two meetings during the week and will look at better ways
>> of expressing issues in the draft. We will review these responses
>> together. For now, I can say that:
>>
>> For point 3.1, last week's (and still current) draft-design spec says
>>
>> "The visibility of FontLibrary fonts is scoped to the current model, and
>> FontLibrary nodes are typically defined with other root nodes in a scene.
>> Fonts from FontLibrary nodes are also usable when defined within an Inline
>> node, or when defined among the topmost nodes of a Prototype instance
>> contained in a scene."
>>
>> These two sentences are attempting to crisply define scene scope. If
>> fonts are defined in the constructs of a scene, then naturally that same
>> scene should see them. Scene-scope visibility is not the same as a child
>> scene has access to the fonts defined in a parent. Likely we should add a
>> sentence to that effect to avoid possible misunderstanding... So we will
>> work on your point 3.1. Perhaps helpful:
>>
>> (rough draft) NOTE. A child scene does not have direct visibility into
>> fonts defined within a parent scene. Meanwhile, if desired, utilizing an
>> X3D Inline model (or external prototype) that contains multiple FontLibrary
>> fonts is a good way for many different X3D scenes to share a consistent set
>> of fonts.
>>
>>
>> For point 3.2, more test cases are always good. However they do not have
>> to all go in the specification, which needs to be clear and concise
>> regarding fundamental requirements. Pursuing each of your test cases is
>> good - but please not in the specification.
>> We think that the current specification has become sufficient to pursue
>> further test cases.
>>
>> In pursuit of test cases, I recommend starting with form shown in EXAMPLE
>> 1. Avoid EXAMPLE 2 form.
>> When we hit edge cases or omissions, we should next look at how HTML5/CSS
>> handles similar cases and consider whether their approach can help.
>> If/when specification gaps or ambiguities are revealed by the test cases,
>> that is the time when we refine the specification.
>>
>>
>> For your point 3.3, the X3D Architecture specification is clear already
>> on what to do when a requested font is not found. We have not seen
>> anything to improve there, the functionality for falling back to
>> alternate-chose fonts seems satisfactory.
>>
>> X3D 4.1 (Draft) Architecture, clause 15 Text component, 15.2.2.2 Font
>> family and style, excerpt:
>>
>> "Any font family may be specified as shown in the following example of
>> the specification of a font family:
>>
>> ["Lucida Sans Typewriter", "Lucida Sans", "Helvetica", "SANS"]
>>
>> In this example, the X3D browser would first look for the font family
>> "Lucida Sans Typewriter" on the system on which the X3D browser is
>> operating. If that is not available, the X3D browser looks for "Lucida
>> Sans". If that is not available, the browser looks for "Helvetica". If that
>> is not available, the X3D browser looks for any sans-serif font. If there
>> are not sans-serif fonts installed, the X3D browser will use any serif font
>> (the default). It is the responsibility of the author that a suitable list
>> of font families be specified so that the desired appearance is achieved in
>> most operating environments. However, the author should always be willing
>> to accept that the requested font families may not be available resulting
>> in the use of a X3D browser-selected "SERIF" font being used."
>>
>>
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#Fontfamilyandstyle
>>
>>
>> For your point 3.4, root node definition was already accepted (with
>> thanks) and addressed by the following changes.
>>
>> X3D 4.1 (Draft) Architecture, clause 4 Concepts, 4.3.2 Root nodes
>>
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#Rootnodes
>> X3D 4.1 (Draft) Architecture, clause 4 Concepts, Figure 4.2 — Interface
>> hierarchy (FontLibrary)
>>
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#f-Objecthierarchy
>>
>>
>> For your point 3.5,
>>
>> the EXAMPLE 2 prose and editors notes certainly acknowledge that the use
>> of FontStyle.fontLibrary can work, but it is a lot more work by the author
>> to get DEF/USE correct and no longer simple to change preferred family
>> field. We think it is an unnecessary alternative.
>> Perhaps we should add in notes that FontStyle.url is nearly equivalent to
>> FontStyle.fontLibrary but is even more work by authors to get correct,
>> repeating a often-lengthy url list every time a font is needed. All of
>> that burden on authors is very error prone. The top-level FontLibrary node
>> honors the Don't Repeat Yourself (DRY) design principle, is terser for the
>> one-time operation of making a new font available, and simply avoids very
>> many possible authoring errors and difficulties.
>> For separation of concerns, we do understand that ImageTexture, Inline,
>> AudioClip etc. have url field included (via X3DUrlObject interface).
>> However, please notice that loading a unique media asset is actually the
>> fundamental functionality of these nodes. These nodes have little other
>> functionality beyond loading a media asset, and also can be used repeatably
>> via DEF/USE to good effect. FontStyle has much other functionality, has
>> numerous legacy implementations that would be suddenly incorrect in X3D
>> 4.1, and an author wants to create multiple
>> similar-and-related-but-different Fontstyle nodes that depend on either
>> fontLibrary or url fields, it is a ton of work. Such a FontStyle cannot be
>> DEF/USEd to adjust the style of a given font (indeed its original and
>> existing purpose). Thus we want to avoid serious complications and leave
>> FontStyle unchanged.
>> Unlike ImageTexture, Inline, AudioClip etc. we do not see a common use
>> case that requires potential reloading of font files - fonts change rarely.
>> Nevertheless FontLibrary X3DUrlObject fields als supports that reload
>> possibility if desired by the author.
>> FontLibrary usage of SFString family field complements existing FontStyle
>> functionality, gives authors control of naming that is independent of (or
>> perhaps complementary to) metadata within a font file, and has several
>> similarities to the HTML5/CSS approach. It provides greatest functionality
>> with most concise approach. It also makes FontStyle.fontLibrary field
>> superfluous, and thus changes to FontStyle become unnecessary.
>> FontLibrary nodes sprinkled throughout a scene as X3DChildNode adds no
>> value if they have scene scope. Thus keeping FontLibrary nodes at the top
>> as root nodes makes sense, with possible additions (as described in draft
>> spec prose) that an Inline or external ProtoInstance can also provide
>> scene-scoped fonts to that parent scene if they contain root-node
>> FontLibrary nodes .
>>
>>
>> Hope this helps. For coming weeks, I do not expect to be able to afford
>> much more time to repeatedly keep going into this kind of detail. Please
>> do consider joining us for a weekly teleconference. If our regular Friday
>> time does not work for you, please propose alternate time windows to Dick
>> and I.
>>
>> Onward we go. Again thanks for your many efforts with X3D.
>>
>>
>> all the best, Don
>>
>> --
>>
>> Don Brutzman Naval Postgraduate School, Code USW/Br
>> brutzman at nps.edu
>>
>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>> +1.831.656.2149
>>
>> X3D graphics, virtual worlds, navy robotics
>> https://faculty.nps.edu/brutzman
>>
>>
>>
>>
>> ________________________________ From: Michalis Kamburelis
>> Sent: Monday, March 17, 2025 4:02 AM
>> To: Brutzman, Donald (Don) (CIV)
>> Cc: Andreas Plesch; X3D; Holger Seelig
>> Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and libraries
>>
>> Hi Don,
>>
>> 1. First of all, much apologies if some of my messaging appeared
>> personal. This was not my intention.
>>
>> I perfectly recognize that we all work on reaching consensus and
>> the best specification. I disagree with you, in this particular
>> thread, on the technical choice ("what is the optimal spec to allow
>> users to customize fonts"), but I absolutely recognize we all work
>> towards the same goal, having a good X3D spec, consistent,
>> implementable, useful for users.
>>
>> We do agree in 100 other topics around X3D, and I'm sure in the
>> future we will agree on 100 more (and disagree on some too!). Our
>> technical discussion doesn't change in any way my respect for your
>> work and recognition that we try to make X3D better.
>>
>> 2. To be clear, when I wrote "Answer from Don" on
>>
>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_1&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898599249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MLY8roX0NWrkmLKGtKLVtPiU3TAJ5XnrgMb6X35fhUw%3D&reserved=0
>> , 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
>>
>>
>>
>
--
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250318/c131111a/attachment-0001.html>
More information about the x3d-public
mailing list