[x3d-public] draft X3D 4.1 prose for font files and libraries
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Sun Mar 23 22:36:17 PDT 2025
Impressive body of work emerging! 🙂👍
Regarding "I think I will add protection for SANS, SERIF and MONOSPACE as reserved names for standard fonts"
The existing specification refers to SANS, SERIF and TYPEWRITER. It also provides important guidance regarding default behaviors if font families listed in the family field are not available.
*
X3D 4.1 (draft) Architecture, clause 15 Text component, 15.2.2.2 Font family and style
*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#Fontfamilyandstyle
So yes, I think it is important to reserve the fallback families. Perhaps we should add specification prose such as
*
X3D browsers shall consider SANS, SERIF, and TYPEWRITER as reserved font family names for fonts that cannot be replaced by another externally loaded font library.
This sensible protection rises to the level of a security precaution: it is possible to consider several forms of harmful mischief (e.g. Impossibly small, scrambled characters, etc.) if a malicious font is somehow loaded. As ever, trusted content and trusted network connections are fundamentally important when authoring and sharing content on the Web.
p.s. Wondering if we should add MONOSPACE as a alternate term for TYPEWRITER ? Seems plausible but... probably not, since we probably first decided on TYPEWRITER because it was an unlikely yet descriptive name for a default. For example, in the following list of fonts, you will not find a TYPEWRITER entry but will find numerous "Mono" variants and three "Monospace" variants.
*
Wikipedia: List of monospaced typefaces
*
https://en.wikipedia.org/wiki/List_of_monospaced_typefaces
[https://upload.wikimedia.org/wikipedia/commons/thumb/7/79/Font-sample-anonymouspro.svg/1200px-Font-sample-anonymouspro.svg.png]<https://en.wikipedia.org/wiki/List_of_monospaced_typefaces>
List of monospaced typefaces - Wikipedia<https://en.wikipedia.org/wiki/List_of_monospaced_typefaces>
Samples of Monospaced typefaces Typeface name Example 1 Example 2 Example 3 Anonymous Pro [1]Bitstream Vera Sans Mono [2]Cascadia Code: Century Schoolbook Monospace
en.wikipedia.org
OTOH, also found several pages willing to share or sell "typewriter" fonts, for example
*
1001 fonts, Typewriter Fonts
*
https://www.1001fonts.com/typewriter-fonts.html
[https://st.1001fonts.net/img/illustrations/a/n/andina-font-13-large.png]<https://www.1001fonts.com/typewriter-fonts.html>
208 Free Typewriter Fonts · 1001 Fonts<https://www.1001fonts.com/typewriter-fonts.html>
These typewriter fonts look like they were written with an old mechanical typewriter.
www.1001fonts.com
Have fun with X3D fonts!
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman
________________________________
From: Andreas Plesch
Sent: Friday, March 21, 2025 9:21 PM
To: Brutzman, Donald (Don) (CIV)
Cc: Extensible 3D (X3D) Graphics public discussion; Holger Seelig
Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and libraries
https://github.com/andreasplesch/x3dom/tree/FontLibrary/test/functional/font_library_questions
now has all of Michalis' question scenes, after some fixes.
They can be selected here:
https://rawgit.com/andreasplesch/x3dom/refs/heads/FontLibrary/test/functional/font_library_questions/all_questions.html
Some results are:
Q4: The FL in parent does affect the Text in the Proto.
Q6: If FL names are duplicated, the last one wins. All FL fonts are actually loaded but only the last one can be found by name.
Q8: FontStyle.style is ignored for FL fonts. The BOLD style does not make the bold FL font even bolder by synthesis which I thought possible.
Generally, the effect of FL is very global, without probably any restriction in scope, up or down level. Ordering is only important for name collision resolution.
This is kind of the 'natural' outcome of the x3dom way of rendering fonts with the help of the web browser css font rendering.
I think I will add protection for SANS, SERIF and MONOSPACE as reserved names for standard fonts.
Is that protection something the standard would want to include ? In my view, yes, to have safe fonts for authors to use.
Cheers, -Andreas
On Fri, Mar 21, 2025 at 12:34 AM Andreas Plesch <andreasplesch at gmail.com<mailto:andreasplesch at gmail.com>> wrote:
I started to translate Michalis very helpful question scenes to xml here:
https://github.com/andreasplesch/x3dom/tree/FontLibrary/test/functional/font_library_questions
They already discovered an issue for relative urls which needed a fix. x3dom's interpretation for the first three can be seen here:
https://rawgit.com/andreasplesch/x3dom/refs/heads/FontLibrary/test/functional/font_library_questions/all_questions.html
As suspected FontLibraries from anywhere are seen everywhere although I noticed that rarely and unreproducibly for question 1 the rendered font seems sans italic and not bold.
Loaded fonts are supposed to be cleared from the web page each time the scene changes.
Another useful Inline question may be what happens if the same family name is used for two different fonts in parent scene and child inline. I suspect for x3dom the first one found wins, eg. is used everywhere.
Another question is a scene which tests if the three standard family names SANS, SERIF and MONOSPACE are protected and cannot be used for FontLibrary.family. I think these should be protected to have safe fallbacks and also a baseline which cannot be changed by and in Inlines.
I will slowly work through the remaining question scenes.
-Andreas
On Thu, Mar 20, 2025 at 12:26 AM Andreas Plesch <andreasplesch at gmail.com<mailto:andreasplesch at gmail.com>> wrote:
For a first cut of FontLibrary on an experimental x3dom branch, here are test scenes:
https://rawgit.com/andreasplesch/x3dom/refs/heads/FontLibrary/test/functional/fonts.html (ctrl-u for code).
The first one uses a new FontLibrary node implementation. The other ones use fonts defined with CSS on the html page, in X3D, which was the traditional x3dom way. Perhaps it will be possible to support more css options (see html context2d.font) with a SFString css-font field for FontStyle which could be expressed as Metadata in x3dom as well (all fields can).
It turns out that with the design, variable fonts can be used as well, meaning only one font file is necessary for all styles (supported by the font).
In fact, I found out that font synthesis for non-variable fonts cannot be turned off in case of rendering fonts on a html canvas, in contrast to regular html font rendering.
Unfortunately, that means that x3dom will have to support font synthesis, which will make it deviate from other x3d browsers. Eg. it will be possible to use FontStyle.style=italic with a plain font file in FontLibrary.url. The synthesis will not be smart enough to go the reverse way.
It also turns out in first testing that the FontLibrary node can occur in the X3D after the FontStyle node because css font loading in html is async anyways,
Next will be checking how Inlines behave. ( I think as if they are just included in the parent x3d scene, without separation either way, eg. the parent can see the Inline FontLibraries, and the Inline can see the parent FontLibraries. This is due to how all fonts are registered to the html document rather than the execution context. Not sure if it will be possible to change that, perhaps with name scope prefixes for font family names.)
Cheers, -Andreas
On Tue, Mar 18, 2025 at 12:00 PM Brutzman, Donald (Don) (CIV) <brutzman at nps.edu<mailto:brutzman at nps.edu>> wrote:
Agreed that the family field is sufficient for author indicating/identifying which font is being applied.
*
Available via identifying SFString family label for each individual FontLibrary font file, and
*
Preferred via FontStyle SFString ordered list of author-preferred family values.
Meanwhile, FontStyle node is place where style information preferred by scene author remains defined.
*
With understanding that not all style options are necessarily supported by all font-file definitions.
We can go very far with this basis. If something else is needed for style information, such that an author needs to add further information for either of these nodes, then our experimentation with implemented examples will reveal whether such a gap can be handled or not by the browser.
*
Extensibility bonus capability for an X3D scene: extra information can always be captured in a contained MetadataString node if browsers want to experiment with further customization.
*
Indeed a contained MetadataString might even provide CSS code for use in adapting a font.
As with CSS, no doubt some corresponding best practices will emerge for X3D. It will be fun to see possible uses when we build a growing set of examples! 🙂
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu<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: Tuesday, March 18, 2025 6:47 AM
To: Andreas Plesch <andreasplesch at gmail.com<mailto:andreasplesch at gmail.com>>
Cc: Holger Seelig <holger.seelig at yahoo.de<mailto:holger.seelig at yahoo.de>>; X3D <x3d-public at web3d.org<mailto:x3d-public at web3d.org>>
Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and libraries
CSS also has the concept of default values. If you don’t specify a CSS property like font-weight, the default value is used.
Best regards,
Holger
--
Holger Seelig
Leipzig, Germany
holger.seelig at yahoo.de<mailto: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<mailto: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<https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_1>
, I meant it literally. I quote precisely your email there, so I
wanted to say where this text comes from. I had no other intention
behind this statement, I just signaled that I literally quote your
mail. I changed it now to say "Spec Decision" and link to your mail,
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Fcommit%2F5cd142f972158450b16c10d95fbbc2985b4f793d&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898622964%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8AAKciDTQKtSJNHNdAzGdmgUh9vV%2BoEU0%2FRbE367YjI%3D&reserved=0<https://github.com/michaliskambi/x3d-tests/commit/5cd142f972158450b16c10d95fbbc2985b4f793d>
, let me know if this correction if satisfactory to you.
3. Going to the technical discussion, I recognize you continue to work
on refining the spec. But various points still seem to be left
unaddressed from the spec prose. I know, that's because this is a long
thread, with many posts, including from me! So that's not an
accusation, I just point out the need for more work. Let me recap
things which I consider still not addressed:
3.1. The sentence "Fonts from FontLibrary nodes are also usable when
defined within an Inline node" is confusing and possibly you meant an
inverse statement, as Andreas already mentioned.
From your past answers, I concluded that
- https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_1&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898636392%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zGiuqSzOERkK75IpUkF1g5AlzeG9eYRdLydatYwo2fo%3D&reserved=0<https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_1>
is valid,
- but https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_2&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898649385%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ajcuNeRXJXBchq9fmCm9pXXygOIofHiYkZoKwpLPxCc%3D&reserved=0<https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_2>
is not valid.
The sentence "Fonts from FontLibrary nodes are also usable when
defined within an Inline node" spec suggests the opposite.
Instead of that sentence, I suggest this (it seems to me it
matches your previous statements):
"""
When using Inline to refer from one X3D file ("parent") to another
X3D file ("child"), the FontLibrary nodes defined in the parent affect
rendering of the children. That is, when the child X3D content refers
to family names using FontStyle, the FontLibrary nodes of the parent
X3D content are searched (in addition to searching the FontLibrary
nodes in child). The inverse is not true: when the parent X3D content
refers to family names using FontStyle, the FontLibrary nodes of the
child X3D content are not searched.
"""
This is longer, but unambiguous.
3.2. I recognize it's OK to be silent (or explicitly say "it's
undefined") for some things, like duplicated family names. OK.
But there are things we really need to clarify, the give X3D
authors a confidence that certain things are supposed to work, in all
browsers.
So we really need to clarify some things. I proposed earlier to
create additional testcases, Andreas provided more ideas too. I have
added now 4 testcases. For each testcase, we need to know the answer,
or consciously say "this is undefined, so various browsers will render
it differently".
See subdirectories with question 5 and up from
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898661912%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZwYi0KcfbTrmQ6ftiHY2pEgvygfWrmIfCIFuAVsLAlU%3D&reserved=0<https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/>
:
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_5_order&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898673973%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BP10XZ7OnXrJMJe1EYqu7ndkMK5vIbcpYEl44FrUVUY%3D&reserved=0<https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_5_order>
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_6_order_and_duplicate_family_names&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898685385%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=f5d3DehISJ57PvkzufHEb2nmvJ4dHfs9uD9uNINl0GY%3D&reserved=0<https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_6_order_and_duplicate_family_names>
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_7_import_export&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898696901%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uNTRubmNqDDWU8Gw94PgbiJR22FFNVAPpBH9JhWx2HA%3D&reserved=0<https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_7_import_export>
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Ftree%2Fmaster%2Ffont_library_questions%2Fquestion_8_unmatched_style&data=05%7C02%7Cbrutzman%40nps.edu%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898707886%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ab1jN2EbKGTJFRNF8sH4aVQCgGT94S7uJMPwO8URQmM%3D&reserved=0<https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_8_unmatched_style>
3.3. We still miss testcases of the font collections, with multiple
fonts, with multiple styles. I do not have resources to look for them.
It seems to me, these font files are rarely used -- but the spec talks
about them, so we need to be able to test them. And test what happens
when e.g. someone requests a family name with a style that isn't
found.
3.4. Me and Andreas both observed that we need to extend "4.3.2 Root
nodes", to explicitly allow FontLibrary as a root node. If the
FontLibrary is not X3DChildNode, then it needs to be explicitly listed
as "allowed root node".
3.5. As for the "separation of concerns", I already voiced how I feel
this is incorrectly applied here.
Other nodes, like textures (ImageTexture), Inline, AudioClip don't
have (and don't need) such separation. Consequently, they don't need
any additional clarification what URL is used for given
texture/audio/inline, because it is explicitly stated. Consequently,
then don't need all these questions and testcases.
It seems that with fonts, we go into something more complicated
(which creates all these questions about "what FontLibrary nodes
match"). And inconsistent with existing way how spec refers to content
(textures, audio, inline).
Anyhow, I recognize I have repeated this statement now multiple
times. We will not reach conclusions by us both repeating the same
arguments :) If others find the FontLibrary workable, then I surely
can accept it too. But let's please address the things mentioned
above.
Best regards,
Michalis
niedz., 16 mar 2025 o 21:21 Brutzman, Donald (Don) (CIV)
<brutzman at nps.edu<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<https://en.wikipedia.org/wiki/Don%27t_repeat_yourself>
Holger's statements about "scene scope" are very clarifying, and are reflected/refined in last week's draft spec update in several places. Thanks Andreas for regular posts about your implementation experience too.
It seems to me like functionality for several of your points is answered by last week's addition.
Proposed. The visibility of FontLibrary fonts is scoped to the current model, and FontLibrary nodes are typically defined with other root nodes in a scene. Fonts from FontLibrary nodes are also usable when defined within an Inline node, or when defined among the topmost nodes of a Prototype instance contained in a scene.
We are intentionally silent about some things. For example, if duplicate fonts are encountered, we do not specify recovery procedures. This is in keeping with X3D design to not require browser responses when behavior is nondeterministic and better left not defined. Of note is that such things (e.g. which font came first?) are usually preventable by authors who can carefully create correct results.
If an issue is so uproarious that it must be mentioned, we might go as far as a "behavior is undefined" note. For example
"NOTE. Behavior is undefined when multiple fonts are defined with the same family name."
X3D Architecture 4.1 (draft) Architecture, clause 15 Text component, 15.4.1 FontLibrary
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontLibrary
Process concerns.
Specification additions are only considered formally once work when consensus is reached. This has been the case without fail since 1995.
Consensus = it works by meeting all goals, and everyone involved can live with whatever seems suboptimal to them (aka "I can live with it"). Can be hard to reach, but is usually easy to tell when we aren't there.
Our carefully phrased refinements did not provide responses in kind, rather you have given a long list of arguments. Does not seem very workable.
Timing: there is no urgency to "reconsider" since there is no deadline whatsoever. If people want the node we will continue towards consensus.
Please depersonalize your online pages. For example, "Answer from Don" is unsatisfactory. We are being scientific, taking an engineering approach.
Our "editors notes" in the draft page try to complement draft spec prose with distilled goals, issues, alternatives, and choices.
Once we have a baseline design to pursue, then agreed that pursuit of test-case examples is constructive and helpful.
Recommendation: you and everyone involved who wants is welcome to please join one of our Friday calls to discuss. When would you like to meet and talk?
Web3D Calendar, X3D Standards Editor weekly meeting
Fridays 09-1000 pacific, regular Web3D zoom line
https://www.web3d.org/calendar/2752/x3d-standards-editors/2025-01-10t170000-2025-01-17t170000-2025-01-24t170000-2025-01
With thanks. Onward we go.
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu<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<https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions>
. I ask people who push for this design of FontLibrary to provide more
testcases.
To be clear, a testcase must be a complete X3D file (not only a
snippet), and it should be accompanied by a text (README file, or
comment inside X3D file) describing the desired effect. It should be
"complete" (so, provide also font files, and all other files
referenced by Inline, EXTERNPROTO). The idea is that browser
implementors can open the testcase, and trivially conclude "my
behavior is correct / incorrect".
Some things that need to be covered by testcases:
- Clarify order: X3D file with FontLibrary node A, than shape B
using a font, then another FontLibrary C. Show unambiguously whether
interpreting B is affected by C or not. In case A and C define the
same family names.
- Show the case of IMPORTing a FontLibrary from Inline. I guess
the IMPORTed FontLibrary node should be searched, as if it was part of
the top-level file?
- Testcases of the font collections, with multiple fonts, with
multiple styles.
- Show what happens when a font family is found within some
FontLibrary, but not with a matching style. Do not leave it in the
spec undefined. Remember that browsers in general cannot "synthesize
the missing style", we agreed in this thread that this is both a
difficult thing and the results have poor quality. So the spec (and
testcases) should qualify what is the fallback then -- should we use
another style from the same family? Should we fallback from font
family "foo", style "italic" -> font family "foo", style "regular"?
And the reverse, should the font family "foo", style "regular" ->
fallback on "foo", style "italic" (if only the latter is available)?
Or should it fallback on the browser default font?
Regards,
Michalis
czw., 13 mar 2025 o 23:16 Andreas Plesch <andreasplesch at gmail.com<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<https://create3000.github.io/x_ite/>
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
--
Andreas Plesch
Waltham, MA 02453
--
Andreas Plesch
Waltham, MA 02453
--
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250324/53e3b975/attachment-0001.html>
More information about the x3d-public
mailing list