[x3d-public] draft X3D 4.1 prose for font files and libraries

Thu Mar 13 10:12:45 PDT 2025

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<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle> and ScreenFontStyle<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/layout.html#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

  1.  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.
  2.  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.
  3.  Whether a single font file contains more than one font; yes, various specifications indicate that may occur for some font files.
  4.
Whether a browser might look inside the font file to check internal metadata and find one of multiple family names; yes that option seems like a good idea if no common matching family field is found for the FontStyle and FontLibrary nodes.

Subject to group scrutiny and discussion, we are ready to

  *

  *
Remove Example 2
     *
Editors note: the fontLibrary fields shown in EXAMPLE 2 appear to be an unnecessary complication, since the approach shown in Example 1 can also work for each of these two scene fragments. Subject to mailing list discussion, we expect to delete both fragments in EXAMPLE 2.
  *

  *
Remove the corresponding FontStyle fontLibrary field in 15.4.2 FontStyle

Hopefully we haven't overlooked reconciliation of any of the many prior discussion points.  Continued scrutiny and discussion remain welcome.

Feels like we are getting close to an excellent design balance.  Hopefully others feel that way too.

Have fun with fonts in X3D!  🙂

all the best, Don

--

Don Brutzman  Naval Postgraduate School, Code USW/Br        brutzman at nps.edu

Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149

X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman

________________________________
From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Holger Seelig via x3d-public <x3d-public at web3d.org>
Sent: Friday, March 7, 2025 2:42 PM
To: X3D <x3d-public at web3d.org>
Cc: Holger Seelig <holger.seelig at yahoo.de>; Andreas Plesch <andreasplesch at gmail.com>
Subject: Re: [x3d-public] draft X3D 4.1 prose for font files and libraries

I think a FontLibrary should be scene scoped and no more. An Inline scene should not have access to the parent scenes FontLibrary nodes registers fonts (via FontLibrary.family field).

In HTML there is a iframe element, the document in this element can’t get access to the parent document, It is completely separated. One reason is that an iframe is often used for advertising which comes often from a different provider and the advertising document should not have access to the parent document for security reasons.

I also think that FontStyle.fontLibrary is not necessary. It makes the code more readable if FontLibrary is a root node.

Best regards,
Holger

--
Holger Seelig
Leipzig, Germany

holger.seelig at yahoo.de
https://create3000.github.io/x_ite/

Am 07.03.2025 um 21:13 schrieb John Carlson via x3d-public <x3d-public at web3d.org>:

On Fri, Mar 7, 2025 at 1:33 PM Brutzman, Donald (Don) (CIV) via x3d-public <x3d-public at web3d.org<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
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250313/5ff1b331/attachment-0001.html>