<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1250">
<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);">
Thanks for your note Michalis.</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="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</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">That 2025-03-07 email clearly indicates it was written and sent following a specification editors 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">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.</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);">
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.</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="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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:</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">For point 3.1, last week's (and still current) draft-design spec says</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(255, 255, 0);">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">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:</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">(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.</div>
</li></ul>
</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>
<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">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.</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">We think that the current specification has become sufficient to pursue further test cases. </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">In pursuit of test cases, I recommend starting with form shown in EXAMPLE 1. Avoid EXAMPLE 2 form.</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">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.</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">If/when specification gaps or ambiguities are revealed by the test cases, that is the time when we refine the specification.</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">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.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<div class="elementToProof"><br>
</div>
</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">X3D 4.1 (Draft) Architecture, clause 15 Text component, 15.2.2.2 Font family and style, excerpt:</div>
</li><ul data-editing-info="{"applyListStyleFromLevel":true}" style="margin-top: 0px; margin-bottom: 0px;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); list-style-type: "∎ ";">
<div class="elementToProof" style="text-align: left; text-indent: 0px; margin-top: 1em; margin-bottom: 1em;">
"Any font family may be specified as shown in the following example of the specification of a font family:</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); list-style-type: "∎ ";">
<pre><div class="elementToProof" style="text-align: left; text-indent: 0px;"> ["Lucida Sans Typewriter", "Lucida Sans", "Helvetica", "SANS"]</div></pre>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); list-style-type: "∎ ";">
<div class="elementToProof" style="text-align: left; text-indent: 0px; margin-top: 1em; margin-bottom: 1em;">
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."</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"><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#Fontfamilyandstyle" id="OWA345e0aa9-dab1-c411-148a-048c1cf4909d" class="OWAAutoLink">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#Fontfamilyandstyle</a></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">For your point 3.4, root node definition was already accepted (with thanks) and addressed by the following changes.</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">X3D 4.1 (Draft) Architecture, clause 4 Concepts, 4.3.2 Root nodes</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/concepts.html#Rootnodes" id="OWAd958600f-d498-0940-af8b-d914593d9751" class="OWAAutoLink">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#Rootnodes</a></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 4.1 (Draft) Architecture, clause 4 Concepts, Figure 4.2 — Interface hierarchy (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/concepts.html#f-Objecthierarchy" id="OWAe4fdf074-a409-9538-d906-cebeb3225415" class="OWAAutoLink">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#f-Objecthierarchy</a></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">For your point 3.5,</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">the EXAMPLE 2 prose and editors notes certainly acknowledge that the use of FontStyle.<i>fontLibrary
</i>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.</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">Perhaps we should add in notes that FontStyle.<i>url </i>
is nearly equivalent to FontStyle.<i>fontLibrary </i>but is even more work by authors to get correct, repeating a often-lengthy
<i>url </i>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.</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">For separation of concerns, we do understand that ImageTexture, Inline, AudioClip etc. have
<i>url </i>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 <i>fontLibrary </i>or <i>url </i>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.</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">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.</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">FontLibrary usage of SFString <i>family </i>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.<i>fontLibrary
</i>field superfluous, and thus changes to FontStyle become unnecessary.</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">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 .</div>
</li></ul>
</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);">
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.</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="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Onward we go. Again thanks for your many efforts with X3D.</div>
<div id="Signature" class="elementToProof">
<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> Monday, March 17, 2025 4:02 AM<br>
<b>To:</b> Brutzman, Donald (Don) (CIV)<br>
<b>Cc:</b> Andreas Plesch; X3D; Holger Seelig<br>
<b>Subject:</b> Re: [x3d-public] draft X3D 4.1 prose for font files and libraries
</span>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Hi Don,<br>
<br>
1. First of all, much apologies if some of my messaging appeared<br>
personal. This was not my intention.<br>
<br>
I perfectly recognize that we all work on reaching consensus and<br>
the best specification. I disagree with you, in this particular<br>
thread, on the technical choice ("what is the optimal spec to allow<br>
users to customize fonts"), but I absolutely recognize we all work<br>
towards the same goal, having a good X3D spec, consistent,<br>
implementable, useful for users.<br>
<br>
We do agree in 100 other topics around X3D, and I'm sure in the<br>
future we will agree on 100 more (and disagree on some too!). Our<br>
technical discussion doesn't change in any way my respect for your<br>
work and recognition that we try to make X3D better.<br>
<br>
2. To be clear, when I wrote "Answer from Don" on</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_1" id="OWA69f91c6c-f3b4-be1b-c0e6-910e7a19bed7" 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%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</a></div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
, I meant it literally. I quote precisely your email there, so I<br>
wanted to say where this text comes from. I had no other intention<br>
behind this statement, I just signaled that I literally quote your<br>
mail. I changed it now to say "Spec Decision" and link to your mail,</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<a href="https://github.com/michaliskambi/x3d-tests/commit/5cd142f972158450b16c10d95fbbc2985b4f793d" id="OWA51986da6-c2ce-6b11-0a4c-8ae1f15971f0" class="OWAAutoLink" data-auth="NotApplicable">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</a></div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
, let me know if this correction if satisfactory to you.<br>
<br>
3. Going to the technical discussion, I recognize you continue to work<br>
on refining the spec. But various points still seem to be left<br>
unaddressed from the spec prose. I know, that's because this is a long<br>
thread, with many posts, including from me! So that's not an<br>
accusation, I just point out the need for more work. Let me recap<br>
things which I consider still not addressed:<br>
<br>
3.1. The sentence "Fonts from FontLibrary nodes are also usable when<br>
defined within an Inline node" is confusing and possibly you meant an<br>
inverse statement, as Andreas already mentioned.<br>
<br>
From your past answers, I concluded that<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
- <a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_1" id="OWAc0f6f395-8a1f-6df1-3e70-a38783a8fd0f" 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%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</a></div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
is valid,</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
- but <a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_2" id="OWAefd8b4f9-fb50-3435-475b-972fc3f6ac23" 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%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</a></div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
is not valid.<br>
<br>
The sentence "Fonts from FontLibrary nodes are also usable when<br>
defined within an Inline node" spec suggests the opposite.<br>
<br>
Instead of that sentence, I suggest this (it seems to me it<br>
matches your previous statements):<br>
<br>
"""<br>
When using Inline to refer from one X3D file ("parent") to another<br>
X3D file ("child"), the FontLibrary nodes defined in the parent affect<br>
rendering of the children. That is, when the child X3D content refers<br>
to family names using FontStyle, the FontLibrary nodes of the parent<br>
X3D content are searched (in addition to searching the FontLibrary<br>
nodes in child). The inverse is not true: when the parent X3D content<br>
refers to family names using FontStyle, the FontLibrary nodes of the<br>
child X3D content are not searched.<br>
"""<br>
<br>
This is longer, but unambiguous.<br>
<br>
3.2. I recognize it's OK to be silent (or explicitly say "it's<br>
undefined") for some things, like duplicated family names. OK.<br>
<br>
But there are things we really need to clarify, the give X3D<br>
authors a confidence that certain things are supposed to work, in all<br>
browsers.<br>
<br>
So we really need to clarify some things. I proposed earlier to<br>
create additional testcases, Andreas provided more ideas too. I have<br>
added now 4 testcases. For each testcase, we need to know the answer,<br>
or consciously say "this is undefined, so various browsers will render<br>
it differently".<br>
<br>
See subdirectories with question 5 and up from</div>
<div class="elementToProof" style="font-size: 11pt;"><a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/" id="OWAae9f290c-ab08-884c-806b-b37234c1cc7b" 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%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</a></div>
<div class="elementToProof" style="font-size: 11pt;">:<br>
<br>
<a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_5_order" id="OWAd9627db6-8839-c49d-0093-3a78b4f5b529" 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%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</a><br>
<br>
<a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_6_order_and_duplicate_family_names" id="OWAcb469a89-9aa1-e5a2-e6f3-6a71697cff68" 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%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</a><br>
<br>
<a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_7_import_export" id="OWAbbf863a6-ad81-623e-b3a1-d616a00cb78d" 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%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</a><br>
<br>
<a href="https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions/question_8_unmatched_style" id="OWA84b08637-93a7-17f8-2aa8-b70870cac9cf" 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%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</a><br>
<br>
3.3. We still miss testcases of the font collections, with multiple<br>
fonts, with multiple styles. I do not have resources to look for them.<br>
It seems to me, these font files are rarely used -- but the spec talks<br>
about them, so we need to be able to test them. And test what happens<br>
when e.g. someone requests a family name with a style that isn't<br>
found.<br>
<br>
3.4. Me and Andreas both observed that we need to extend "4.3.2 Root<br>
nodes", to explicitly allow FontLibrary as a root node. If the<br>
FontLibrary is not X3DChildNode, then it needs to be explicitly listed<br>
as "allowed root node".<br>
<br>
3.5. As for the "separation of concerns", I already voiced how I feel<br>
this is incorrectly applied here.<br>
<br>
Other nodes, like textures (ImageTexture), Inline, AudioClip don't<br>
have (and don't need) such separation. Consequently, they don't need<br>
any additional clarification what URL is used for given<br>
texture/audio/inline, because it is explicitly stated. Consequently,<br>
then don't need all these questions and testcases.<br>
<br>
It seems that with fonts, we go into something more complicated<br>
(which creates all these questions about "what FontLibrary nodes<br>
match"). And inconsistent with existing way how spec refers to content<br>
(textures, audio, inline).<br>
<br>
Anyhow, I recognize I have repeated this statement now multiple<br>
times. We will not reach conclusions by us both repeating the same<br>
arguments :) If others find the FontLibrary workable, then I surely<br>
can accept it too. But let's please address the things mentioned<br>
above.<br>
<br>
Best regards,<br>
Michalis<br>
<br>
niedz., 16 mar 2025 o 21:21 Brutzman, Donald (Don) (CIV)<br>
<brutzman@nps.edu> napisa³(a):<br>
><br>
> Appreciate your point of view Michalis. Also appreciate much careful thinking by everyone.<br>
><br>
> Dick and I have been reviewing everything regularly. We have been responsive throughout.<br>
><br>
> This is not a battle or contest of wills. We are searching for a consensus solution balancing multiple concerns:<br>
><br>
><br>
> correctness with other font specifications,<br>
> consistency with existing X3D design,<br>
> Implementation ability by browsers,<br>
> Authoring concerns: simplicity, repeatability, scalability (X in X3D), testability, workable across all file formats and programming languages.<br>
> Coherency of design in combination with HTML CSS and<br>
> Simplicity when possible, to avoid a variety of problems.<br>
><br>
><br>
> 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.<br>
><br>
> 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.<br>
> 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.<br>
><br>
> <a href="https://en.wikipedia.org/wiki/Don%27t_repeat_yourself" id="OWA04e4787c-8d5c-ea07-2e4d-7940de947791" class="OWAAutoLink" data-auth="NotApplicable">
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</a><br>
><br>
> 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.<br>
> It seems to me like functionality for several of your points is answered by last week's addition.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> If an issue is so uproarious that it must be mentioned, we might go as far as a "behavior is undefined" note. For example<br>
> "NOTE. Behavior is undefined when multiple fonts are defined with the same family name."<br>
><br>
><br>
> X3D Architecture 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="OWAe6f1ac2b-48da-7b35-7d3a-d43d398c6253" 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>
> Process concerns.<br>
><br>
> Specification additions are only considered formally once work when consensus is reached. This has been the case without fail since 1995.<br>
> 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.<br>
> Our carefully phrased refinements did not provide responses in kind, rather you have given a long list of arguments. Does not seem very workable.<br>
> Timing: there is no urgency to "reconsider" since there is no deadline whatsoever. If people want the node we will continue towards consensus.<br>
> Please depersonalize your online pages. For example, "Answer from Don" is unsatisfactory. We are being scientific, taking an engineering approach.<br>
> Our "editors notes" in the draft page try to complement draft spec prose with distilled goals, issues, alternatives, and choices.<br>
> Once we have a baseline design to pursue, then agreed that pursuit of test-case examples is constructive and helpful.<br>
><br>
><br>
> 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?<br>
><br>
> Web3D Calendar, X3D Standards Editor weekly meeting<br>
> Fridays 09-1000 pacific, regular Web3D zoom line<br>
> <a href="https://www.web3d.org/calendar/2752/x3d-standards-editors/2025-01-10t170000-2025-01-17t170000-2025-01-24t170000-2025-01" id="OWA27af43d4-3f7b-41b4-4eae-e4c7756a9a06" class="OWAAutoLink" data-auth="NotApplicable">
https://www.web3d.org/calendar/2752/x3d-standards-editors/2025-01-10t170000-2025-01-17t170000-2025-01-24t170000-2025-01</a><br>
><br>
> With thanks. Onward we go.<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="OWAbc40a64e-a298-be36-aa46-b38bd5606d44" class="OWAAutoLink" data-auth="NotApplicable">
https://faculty.nps.edu/brutzman</a><br>
><br>
><br>
><br>
><br>
> ________________________________ From: Michalis Kamburelis<br>
> Sent: Friday, March 14, 2025 3:39 AM<br>
> To: Andreas Plesch<br>
> Cc: Brutzman, Donald (Don) (CIV); X3D; Holger Seelig<br>
> Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and libraries<br>
><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="OWA4a2c3fbd-02a0-63a2-384d-24db77d030d5" 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%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898732868%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w6xIoQYFb0z9cU8cE%2BAdaVK3fYBLplJHhMCKw1wKHcQ%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="OWA28550ec0-8d7c-505e-5f72-f58a00fd2f47" 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="OWA95662b0f-682c-5861-0421-700bb475d09b" 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="OWAdc72e825-f134-ff57-3655-5eeed5c4fbed" 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%7C1dc38307e40c4b2eb03b08dd654348ed%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638778061898745164%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yRAaVbY3QwiJu5T9Hk16fPwRx%2BOGnyh5AgZsryyStiw%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="OWA20a75d97-6a0a-e09b-0684-36054f0b201f" class="OWAAutoLink" data-auth="NotApplicable">
http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
> >><br>
> >><br>
</div>
</body>
</html>