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

[Michalis Kamburelis]

Hello Don!

Answers inline below:

> Dick and I are only seeing three of them on your website this morning.

The
https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions
contains 4 questions, but one question is not in a dedicated subdirectory,
I guess this was confusing :) It's in the file
question_3_font_library_search.x3dv .

>  Question 1.  rephrased: does a child scene, Inlined by a parent scene,
have access to FontLibrary fonts defined in the parent?
>
> Summary:  downward scope to descendant models.

OK. I think I'm fine with any answer here (as long as it's unambiguous and
then encoded in spec). So FontLibrary in parent affects the child.

( It would be easier to implement if the FontLibrary scope was limited only
to this file, but I can live with any choice. )

> Question 2.
>
> As indicated in our response to Question 2, we think it is possible but
generally not desirable.
...
> We do not think that FontLibrary should be an X3DBindableNode (like Fog,
Viewpoint, Background etc.)  However if an implementer wants to use a stack
internally to implement such downward-looking scope, that is up to them.

OK, agreed. That is, FontLibrary in child *does not* affect the parent.

To be clear, I didn't suggest that it should be X3DBindableNode.
FontLibrary is very different from X3DBindableNode. My comment in
https://github.com/michaliskambi/x3d-tests/blob/master/font_library_questions/question_2/README.md
merely indicates that drawing analogies (which I did myself) between "how
`Fog` works" and "how `FontLibrary` should work" has limits, because `Fog`
has a "bindable" mechanism (only one is active at a time), while
`FontLibrary` is not (many `FontLibrary` can be top-level and affect
content). We are in agreement here as I understand, i.e. FontLibrary is
*not* X3DBindableNode, this would make no sense.

>  Question 4.  Looks similar to question 2, using
ExternProtoDeclare/ProtoInstance rather than Inline.  (But very tricky!
 thanks!)
...
> FontLibrary fonts are available for reference and retrieval in the scene
where the ProtoInstance is created at run-time.

OK, makes sense.

I see you also considered should the FontLibrary be allowed as top-level in
prototype, and the conclusion is: it should not be. I agree. Keep things
simple, FontLibrary only at top-level.

> We continue to think that FontLibrary as root node (with full
X3DUrlObject functionality) is necessary for 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 have to say I still don't agree:

- "Separation of concerns" is unnecessary here, and we don't do such
separation of concerns in any other place in X3D. We have ImageTexture with
URL, and noone wants to introduce an ImageLibrary. We have AudioClip and
other nodes. So FontLibrary is a very non-standard design, contrary to the
rest of X3D.

    I see John noticed exactly the same thing.

    Note that ImageTextureAtlas (
https://create3000.github.io/x_ite/components/texturing3d/imagetextureatlas/
) is just a 3D texture. It's *not* like a (speculated) ImageLibrary, in the
sense that it doesn't bring and new way to associate textures with
appearances. ImageTextureAtlas is just a texture (and the association
follows standard rules and 3D texture coordinates, from what I know).

- And this is causing significant implementation burden, with no
significant benefit to users, IMHO.

     Because the fonts are associated by family name, the DEF/USE of
FontLibrary is not useful, which is contrary to how one reuses e.g.
textures, sounds. You also have explicit problems for implementations
mentioned in this thread: now implementations need to parse font files to
extract family names, to make the associations. Andreas said that X3DOM
will likely not do this, and rely *only* on family name being spelled
explicitly, from what I understand.

    And the answers to my questions from
https://github.com/michaliskambi/x3d-tests/tree/master/font_library_questions
are also additional work for implementations. We need to maintain the
"available FontLibrary" for every X3D file and properly search them,
accounting that a node may be in a child Inline, or in a prototype instance.

- And there's just not enough benefit from this design, IMHO...

    The common use-case, that really happens in reality (based on my
experience speaking with Castle Game Engine users): """User has X3D with a
text and a TTF file with a font (with single family and style). User wants
to tell "use this TTF to render this text". """

    FontStyle.url is just solving this need in a direct way. We already
have FontStyle to customize the font, it's obvious to users to look for an
option to specify TTF there, it's trivial for implementations to support
it. And font collections could be supported by simple `url
"my-collection.ttc#123"`. And DEF/USE of FontStyle would make sense, and
reuse the font file. That's exactly how our ImageTexture and other texture
nodes work!

    In contrast, we go with FontLibrary, where the association is "by
family name", which forces us to read font files beforehard, and to do
additional logic "which FontLibrary to search".

    ( P.S. I deliberately give here an example with TTF. Although we like
OTF, although we like WOFF... but in practice, most people still use the
oldest standard, TTF, that's my statistics. Just because they can find a
ton of TTF files on the Internet, and *every* font software can support
TTF. )

Anyhow, I guess I repeated myself enough times :) I'm sorry, but I still
really see FontLibrary as unnecessary complication, and I'm in favor of
going back to FontStyle.url.

All the same, thank you for the discussion, for reading my long mails and
answering testcases.

Regards,
Michalis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250308/5d6bb53e/attachment.html>