<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Appreciate your point of view Michalis. Also appreciate much careful thinking by everyone.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Dick and I have been reviewing everything regularly. We have been responsive throughout.</div>
<div class="elementToProof" style="margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
This is not a battle or contest of wills. We are searching for a consensus solution balancing multiple concerns:</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
</div>
<ul data-editing-info="{"applyListStyleFromLevel":false,"unorderedStyleType":1}" style="margin-top: 0px; margin-bottom: 0px; list-style-type: disc;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">correctness with other font specifications,</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">consistency with existing X3D design,</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Implementation ability by browsers, </div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Authoring concerns: simplicity, repeatability, scalability (X in X3D), testability, workable across all file formats and programming languages.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Coherency of design in combination with HTML CSS and </div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Simplicity when possible, to avoid a variety of problems.</div>
</li></ul>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<ul data-editing-info="{"applyListStyleFromLevel":false,"unorderedStyleType":1}" style="margin-top: 0px; margin-bottom: 0px; list-style-type: disc;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">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. </div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">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.</div>
</li><ul data-editing-info="{"applyListStyleFromLevel":true}" style="margin-top: 0px; margin-bottom: 0px; list-style-type: circle;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof"><a href="https://en.wikipedia.org/wiki/Don%27t_repeat_yourself" id="LPlnk">https://en.wikipedia.org/wiki/Don%27t_repeat_yourself</a></div>
<div><br>
</div>
</li></ul>
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">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.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">It seems to me like functionality for several of your points is answered by last week's addition.</div>
</li><ul data-editing-info="{"applyListStyleFromLevel":true}" style="margin-top: 0px; margin-bottom: 0px; list-style-type: circle;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof"><span style="background-color: rgb(128, 255, 255);">Proposed</span>.
<span style="background-color: rgb(255, 255, 128);">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.</span></div>
</li></ul>
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">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.</div>
</li><ul data-editing-info="{"applyListStyleFromLevel":true}" style="margin-top: 0px; margin-bottom: 0px; list-style-type: circle;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">If an issue is so uproarious that it must be mentioned, we might go as far as a "behavior is undefined" note. For example</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">"NOTE. Behavior is undefined when multiple fonts are defined with the same family name."</div>
</li></ul>
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); display: block;">
<div class="elementToProof"><br>
</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">X3D Architecture 4.1 (draft) Architecture, clause 15 Text component, 15.4.1 FontLibrary</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof"><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontLibrary" id="LPlnk">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontLibrary</a></div>
</li></ul>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Process concerns.</div>
<ul data-editing-info="{"applyListStyleFromLevel":false,"unorderedStyleType":1}" style="margin-top: 0px; margin-bottom: 0px; list-style-type: disc;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Specification additions are only considered formally once work when consensus is reached. This has been the case without fail since 1995.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">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.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof" style="margin: 0px;">Our carefully phrased refinements did not provide responses in kind, rather you have given a long list of arguments. Does not seem very workable.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Timing: there is no urgency to "reconsider" since there is no deadline whatsoever. If people want the node we will continue towards consensus.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Please depersonalize your online pages. For example, "Answer from Don" is unsatisfactory. We are being scientific, taking an engineering approach.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Our "editors notes" in the draft page try to complement draft spec prose with distilled goals, issues, alternatives, and choices.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Once we have a baseline design to pursue, then agreed that pursuit of test-case examples is constructive and helpful.</div>
</li></ul>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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?</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<ul data-editing-info="{"applyListStyleFromLevel":false,"unorderedStyleType":1}" style="margin-top: 0px; margin-bottom: 0px; list-style-type: disc;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Web3D Calendar, X3D Standards Editor weekly meeting</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof">Fridays 09-1000 pacific, regular Web3D zoom line</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof"><a href="https://www.web3d.org/calendar/2752/x3d-standards-editors/2025-01-10t170000-2025-01-17t170000-2025-01-24t170000-2025-01" id="LPlnk">https://www.web3d.org/calendar/2752/x3d-standards-editors/2025-01-10t170000-2025-01-17t170000-2025-01-24t170000-2025-01</a></div>
<div class="elementToProof"><br>
</div>
</li></ul>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
With thanks. Onward we go.</div>
<div class="elementToProof" id="Signature">
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;"><br>
</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;">all the best, Don</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;">--</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;">Don Brutzman Naval Postgraduate School, Code USW/Br brutzman@nps.edu</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;">Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;">X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: "Courier New"; font-size: 9pt;"> </span></p>
</div>
<div id="appendonsend"></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><b>From:</b> Michalis Kamburelis<br>
<b>Sent:</b> Friday, March 14, 2025 3:39 AM<br>
<b>To:</b> Andreas Plesch<br>
<b>Cc:</b> Brutzman, Donald (Don) (CIV); X3D; Holger Seelig<br>
<b>Subject:</b> Re: [x3d-public] draft X3D 4.1 prose for font files and libraries
</span>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
<br>
From my side:<br>
<br>
1. I already voiced a few times that I find this "FontLibrary" design<br>
incorrect. We go into a complicated design with various edge-cases --<br>
which FontLibrary nodes are searched, in what order, and how does this<br>
searching interact with Inline, EXTERNPROTO. Oh, and IMPORT (we didn't<br>
talk about it yet). The spec doesn't answer these questions in a<br>
precise way right now.<br>
<br>
And we have technical limitations of some browsers to read the<br>
font files before they are rendered (thus extracting family name from<br>
font file contents), to support font collections, to enumerate all<br>
fonts in a font collection.<br>
<br>
This means -> the spec will not be handled consistently with all<br>
the browsers. We already know this, for sure (given technical<br>
limitations voiced in this thread). That's bad for users.<br>
<br>
I still have not heard a convincing argument why a more<br>
straightforward "FontStyle.url" was rejected. "FontStyle.url" seems<br>
like a straightforward solution that avoids all the pitfalls of<br>
"FontLibrary", because the association between FontStyle <-> font file<br>
is just explicit. All the existing X3D mechanisms (Inline,<br>
EXTERNPROTO, IMPORT, DEF/USE) have obvious application in this case.<br>
<br>
From what I can see, all the X3D browsers can support, or even<br>
support already, "FontStyle.url" in an unambiguous way. On the other<br>
side, the "FontLibrary" has a number of optional features that are<br>
already known to be impossible for some implementations, and we still<br>
have a number of open questions, not clarified by the spec, how<br>
"FontLibrary" should behave.<br>
<br>
I really ask one more time to reconsider. This long long thread is<br>
a proof in itself: we keep talking, and we keep finding more and more<br>
holes in "FontLibrary" design. Let's turn back :)<br>
<br>
2. In case my plea from AD 1 is ignored, we at least definitely need<br>
more testcases covering the questions from AD 1. I already made some,<br>
<a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions" id="OWAef2c0821-8e1b-57c7-d74e-d93e077ae959" class="OWAAutoLink" data-auth="NotApplicable">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%7Cc506e47fb42742b2a34d08dd62e4a401%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638775456364432214%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gOeSE5og%2FV2Znh6UOjwCt3I2Lkhdkj1i6FBWORABazY%3D&reserved=0</a><br>
. I ask people who push for this design of FontLibrary to provide more<br>
testcases.<br>
<br>
To be clear, a testcase must be a complete X3D file (not only a<br>
snippet), and it should be accompanied by a text (README file, or<br>
comment inside X3D file) describing the desired effect. It should be<br>
"complete" (so, provide also font files, and all other files<br>
referenced by Inline, EXTERNPROTO). The idea is that browser<br>
implementors can open the testcase, and trivially conclude "my<br>
behavior is correct / incorrect".<br>
<br>
Some things that need to be covered by testcases:<br>
<br>
- Clarify order: X3D file with FontLibrary node A, than shape B<br>
using a font, then another FontLibrary C. Show unambiguously whether<br>
interpreting B is affected by C or not. In case A and C define the<br>
same family names.<br>
<br>
- Show the case of IMPORTing a FontLibrary from Inline. I guess<br>
the IMPORTed FontLibrary node should be searched, as if it was part of<br>
the top-level file?<br>
<br>
- Testcases of the font collections, with multiple fonts, with<br>
multiple styles.<br>
<br>
- Show what happens when a font family is found within some<br>
FontLibrary, but not with a matching style. Do not leave it in the<br>
spec undefined. Remember that browsers in general cannot "synthesize<br>
the missing style", we agreed in this thread that this is both a<br>
difficult thing and the results have poor quality. So the spec (and<br>
testcases) should qualify what is the fallback then -- should we use<br>
another style from the same family? Should we fallback from font<br>
family "foo", style "italic" -> font family "foo", style "regular"?<br>
And the reverse, should the font family "foo", style "regular" -><br>
fallback on "foo", style "italic" (if only the latter is available)?<br>
Or should it fallback on the browser default font?<br>
<br>
Regards,<br>
Michalis<br>
<br>
czw., 13 mar 2025 o 23:16 Andreas Plesch <andreasplesch@gmail.com> napisał(a):<br>
><br>
> Thanks for further careful consideration and adjustments. Hopefully, it is not too late to add to the discussion further.<br>
><br>
> 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.<br>
><br>
> Thus, please consider that support for font collections is explicitly made optional, or only guaranteed at a higher component level.<br>
><br>
> 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.<br>
><br>
> Third, is ordering important ? Can a FontStyle node only occur after a FontLibray node it references (similar to USE after DEF) ?<br>
><br>
> Fuller discussion:<br>
><br>
> 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:<br>
><br>
> "Fonts from FontLibrary nodes are also usable when defined within an Inline node"<br>
><br>
> 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 ?<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Any feedback or thoughts appreciated,<br>
><br>
> Andreas Plesch<br>
> Waltham, MA 02453<br>
><br>
> On Thu, Mar 13, 2025, 1:12 PM Brutzman, Donald (Don) (CIV) <brutzman@nps.edu> wrote:<br>
>><br>
>> Holger, thanks for these carefully expressed points, very convincing. Also thanks to others for steadily progressing dialog on this topic.<br>
>><br>
>> Dick and I met yesterday and looked closely at how to express "scene scope" satisfactorily.<br>
>><br>
>> X3D 4.1 (draft) Architecture, clause 15 Text component, 15.4.1 FontLibrary<br>
>> <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontLibrary" id="OWAbaf8f971-cf5f-f8e8-914d-71f144712a05" class="OWAAutoLink" data-auth="NotApplicable">
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontLibrary</a><br>
>><br>
>><br>
>> Summary of latest revision follows. (color-code reminder: yellow is proposed, cyan is editors note)<br>
>><br>
>> FontLibrary family field is an important addition that resolves several challenges, we are ready to accept it.<br>
>><br>
>> Current node definition:<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> Proposed addition:<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> Keeping track of design rationale, we combined several thoughts as follows.<br>
>><br>
>> Editors note: key questions are<br>
>><br>
>> 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.<br>
>> 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.<br>
>> Whether a single font file contains more than one font; yes, various specifications indicate that may occur for some font files.<br>
>> 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.<br>
>><br>
>><br>
>> Subject to group scrutiny and discussion, we are ready to<br>
>><br>
>><br>
>> Remove Example 2<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> Remove the corresponding FontStyle fontLibrary field in 15.4.2 FontStyle<br>
>><br>
>><br>
>> Hopefully we haven't overlooked reconciliation of any of the many prior discussion points. Continued scrutiny and discussion remain welcome.<br>
>><br>
>> Feels like we are getting close to an excellent design balance. Hopefully others feel that way too.<br>
>><br>
>> Have fun with fonts in X3D! 🙂<br>
>><br>
>><br>
>> all the best, Don<br>
>><br>
>> --<br>
>><br>
>> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman@nps.edu<br>
>><br>
>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
>><br>
>> X3D graphics, virtual worlds, navy robotics <a href="https://faculty.nps.edu/brutzman" id="OWAd2478602-cc3b-7921-bc17-ad0107cd8dc0" class="OWAAutoLink" data-auth="NotApplicable">
https://faculty.nps.edu/brutzman</a><br>
>><br>
>><br>
>><br>
>> ________________________________<br>
>> From: x3d-public <x3d-public-bounces@web3d.org> on behalf of Holger Seelig via x3d-public <x3d-public@web3d.org><br>
>> Sent: Friday, March 7, 2025 2:42 PM<br>
>> To: X3D <x3d-public@web3d.org><br>
>> Cc: Holger Seelig <holger.seelig@yahoo.de>; Andreas Plesch <andreasplesch@gmail.com><br>
>> Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and libraries<br>
>><br>
>> 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).<br>
>><br>
>> 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.<br>
>><br>
>> I also think that FontStyle.fontLibrary is not necessary. It makes the code more readable if FontLibrary is a root node.<br>
>><br>
>> Best regards,<br>
>> Holger<br>
>><br>
>> --<br>
>> Holger Seelig<br>
>> Leipzig, Germany<br>
>><br>
>> holger.seelig@yahoo.de<br>
>> <a href="https://create3000.github.io/x_ite/" id="OWA8abb42e7-e05e-90f0-4384-e315d1ceb45a" class="OWAAutoLink" data-auth="NotApplicable">
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2F&data=05%7C02%7Cbrutzman%40nps.edu%7Cc506e47fb42742b2a34d08dd62e4a401%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638775456364451713%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iyWilLSlQC0ZFwjvGe0pve0S87pT89TXO%2BmNaBL2tkY%3D&reserved=0</a><br>
>><br>
>> Am 07.03.2025 um 21:13 schrieb John Carlson via x3d-public <x3d-public@web3d.org>:<br>
>><br>
>><br>
>><br>
>> On Fri, Mar 7, 2025 at 1:33 PM Brutzman, Donald (Don) (CIV) via x3d-public <x3d-public@web3d.org> wrote:<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> 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?<br>
>><br>
>> John<br>
>> _______________________________________________<br>
>> x3d-public mailing list<br>
>> x3d-public@web3d.org<br>
>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" id="OWA6a57b97c-783e-6f49-9ed3-ac0ca36776ae" class="OWAAutoLink" data-auth="NotApplicable">
http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>><br>
>><br>
</div>
</body>
</html>