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

[Andreas Plesch]

I understand that global scope is preferred if the concept of the
FontLibrary node is that an author can add a font to the existing set of
system fonts, and then be used in the same way as installed system fonts. I
think this is the rationale for the current design as root node although I
am not sure it has been stated as such.

However, this concept is questionable since X3D otherwise does not have a
way to use system resources, like system sounds. Instead, all resources are
provisioned within the scene, typically with a resource locator, or url.
Sounds, videos or textures, for example. X3D then uses such a resource
locally, for example in an Appearance node. There is no global texture or
sound library.

This is the argument that a FontLibray node which would hold a url
should be treated the same way as all other resources a X3D file uses.
Scene fonts should not be special, relative to other resources. Scene fonts
should not be treated as system fonts.

FontLibrary therefore should also be a field with local scope, like all
other resources. There could be a Text.fontLibray field if
FontStyle.fontLibrary is non-preferred due to complexity concerns. Such a
field also would address scoping and matching questions unambiguously.

More about scope:

On Sun, Mar 16, 2025 at 4:21 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

>
>    - 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.
>
>
I hope I can contribute. Providing an X3D example using a font file with a
collection of multiple fonts would help with implementation efforts since
the selection process seems undefined so far.


>    -
>    - It seems to me like functionality for several of your points is
>    answered by last week's addition.
>    - Proposed. The visibility of FontLibrary fonts is scoped to the
>       current model, and FontLibrary nodes are typically defined with other root
>       nodes in a scene. Fonts from FontLibrary nodes are also usable when defined
>       within an Inline node, or when defined among the topmost nodes of a
>       Prototype instance contained in a scene.
>
>
This was not very clear to me, unfortunately. Let me repeat my question
here:

"Fonts from FontLibrary nodes are also usable when defined within an Inline
node"
 means (to me) that if an Inline node has a font defined in a FontLibrary
root node within it, it is usable also in the parent node.

Is this the intended meaning ?

I think this is the opposite of the iframe case which Holger mentioned, so
the sentence may actually be intended to mean the opposite ?

Perhaps I misunderstand what 'defined' refers to.

As Joe points out, scope in X3D is tightly coupled to execution context.
Execution context is well understood.


>    -
>    - We are intentionally silent about some things.  For example, if
>    duplicate fonts are encountered, we do not specify recovery procedures.
>    This is in keeping with X3D design to not require browser responses when
>    behavior is nondeterministic and better left not defined.  Of note is that
>    such things (e.g. which font came first?) are usually preventable by
>    authors who can carefully create correct results.
>    - If an issue is so uproarious that it must be mentioned, we might go
>       as far as a "behavior is undefined" note.  For example
>       - "NOTE. Behavior is undefined when multiple fonts are defined with
>       the same family name."
>
>
Being silent allows diverging browser behaviours which may be an acceptable
price.
Ordering then seems to be one of the things which do not need language.
Browsers would be allowed to be picky and assume that FontLibrary before
FontStyle order would be natural.

Hopefully, this can be seen as constructive,
-Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250316/38bb9ec9/attachment.html>