[x3d-public] draft X3D 4.1 prose for font files and libraries
Andreas Plesch
andreasplesch at gmail.com
Sun Mar 2 10:30:13 PST 2025
Thanks, that looks great. I just wish there was a way to avoid 300kb of
opentype.js and 300kb of wawoff2.js just to extract names.
The name table information embedded in the example woff2 file includes:
fontFamilyen Playwrite CA GuidesfontSubfamilyen RegularfullNameen Playwrite
CA Guides Regular
Which name should a x3d browser use for matching with FontStyle.family ?
Best effort ? Ignore spaces, as common in file names ? That could lead to
different interpretations. Why not avoid any ambiguity and follow CSS
allowing authors to explicitly associate a font from a file with a
FontStyle, as Holger originally proposed ?
Best, -Andreas
On Sun, Mar 2, 2025 at 7:21 AM Holger Seelig <holger.seelig at yahoo.de> wrote:
> It seems I was wrong with my last email.
>
> I created a reference implementation of FontLibrary node to test and play
> with.
>
> It is available at:
>
> https://create3000.github.io/test/?url=https://gist.githubusercontent.com/create3000/6d3992dea7e641bb59645684ca468ce7/raw/a63e66e23b305478fbfdee9e67d7db9cad1f8e72/FontLibrary.x3dv
>
> Best regards,
> Holger
>
> --
> Holger Seelig
> Leipzig, Germany
>
> holger.seelig at yahoo.de
> https://create3000.github.io/x_ite/
>
> Am 02.03.2025 um 05:26 schrieb Andreas Plesch via x3d-public <
> x3d-public at web3d.org>:
>
> Ok, I think these explanations make the intention very clear.
>
> On Sat, Mar 1, 2025 at 3:29 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
>> Thanks for careful scrutiny and questions. Overall responses:
>>
>> 1. We have not seen a need for FontLibrary to be referenced in the
>> field of any other node. It adds to the fonts available in the browser.
>>
>> Then a FontLibrary node needs to be able to be a root node:
> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/concepts.html#Rootnodes
> So it could be a ChildNode or another class of root nodes.
>
>>
>> 1.
>> 2. If someone has a use case where FontLibrary needs to be
>> specifically referred to by individual FontStyle or ScreenFontStyle nodes,
>> please state it.
>>
>> This would clearly associate a font with an individual FontStyle and
> avoid mistakes.
> In rare cases there may be two different fonts which have the same
> family name. There is no central registry for font family names.
>
>
>> 1.
>> 2. Since fonts themselves change so infrequently, keeping FontLibrary
>> scope global and not requiring reloads of any given url (local file or
>> online) seems sensible.
>>
>> Rereferencing by DEF/USE a FontStyle.fontLibrary would not require
> reloads. In terms of loading efficiency it does not matter if the scope is
> Scene or FontStyle/Text.
>
>
>> 1.
>> 2. Since X3DUrlNode functionality of the url (and related) fields
>> offers so much functionality, making X3DUrlNode an abstract interface for
>> FontLibrary adds much common functionality found in other X3DUrlNode nodes
>> that have url functionality (Anchor, ImageTexture, Inline, and others).
>> This simplifies implementations, keeps functionality consistent, and
>> provides well-understood semantics to authors. Furthermore, allowing an
>> author to selectively load a new font file at run time offers greater
>> flexibility for textual presentation and animation
>>
>>
>
>>
>> 1.
>> 2. Having url and run-time capabilities means that FontLibrary would
>> be an X3D node, not an X3D statement.
>>
>> True. The statement role just seems to fit better as FontLibray would not
> be referenced by any field. Perhaps there is a way to adopt the url field
> for such a statement.
>
>>
>> 1.
>> 2. The availability of DEF and USE capabilities is perhaps not needed
>> for regular use. Nevertheless it might provide interesting options if an
>> author wants to use FontLibrary in combination with Script or
>> ProtoDeclare/ExternProtoDeclare functionality. For example, a scene might
>> have a Script or ProtoInstance that uses a specific custom
>> ExternProtoDeclare reference. Several possibilities for advanced authoring
>> here, just taking advantage of existing X3D flexibility and extensibility.
>>
>> See *response* paragraphs inserted below for specific replies.
>>
>>
> *response: *We are thinking that if inconsistencies exist between a
>> specified FontStyle family field and the font file, then such cases are
>> best handled on a best-effort basis by browsers without further complex
>> (and possibly contradictory) guidance in specification prose. Perhaps this
>> stance should be a NOTE?
>>
>
> Another source of conflict is the font family name. While most (perhaps
> not all) font files contain a correct family name, it is difficult to
> extract and requires a library. For example, web browsers do not extract
> the family name from a font file, and therefore do not rely on such an
> extracted name. An author may not even know the exact font name as
> contained in a font file. The family names shown in online font collections
> may not match exactly what is contained in a file.
> Don's example scene is actually a victim of this potential for confusion.
> The family name Playwright_CA_Guides is in reality not the same name as
> given in the woff2 file. I think it is Playwright CA Guides. I may be
> responsible for this since I used it in an example but it shows how quickly
> this can go wrong.
> The solution in CSS is to allow authors to define their own family name
> for the font given in the font file.
> The X3D equivalent would be to add a SFString FontLibrary.family field
> which would be the authoritative family name. The family name in the font
> file would be ignored.
> Then the author can use the same name in the FontStyle.family field. This
> starts to sound a lot like DEF/USE names which would work similarly for a
> Font Style.font Library field node.
>
> So please consider adding a SFString FontLibrary.family field to
> FontLibrary.
>
> I think x3dom may not be able to fully implement FontLibrary if extraction
> of the family name from the font file is necessary since the size of the
> needed libraries may not be commensurate with the added benefit.
>
> How does FontLibrary define a "collection of one or more font families" ?
> Is there an example of a font file containing more than one font family ?
>
> "An empty *url* list indicates that the default set of fonts provided by
> the browser are used."
>
> The url field always exists but can be empty. So is optional and could be
> removed.
> Is that case different from not providing a FontLibrary node at all ? If
> not, perhaps make this stronger: "list is equivalent to not including the
> FontLibrary node."
>
> Andreas
>
> P.S. Interesting reference
>>
>> - Google Fonts: Using type in AR & VR
>> - https://fonts.google.com/knowledge/using_type_in_ar_and_vr
>>
>>
>> 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 Andreas
>> Plesch via x3d-public <x3d-public at web3d.org>
>> *Sent:* Saturday, March 1, 2025 6:45 AM
>> *To:* X3D Graphics public mailing list <x3d-public at web3d.org>
>> *Cc:* Andreas Plesch <andreasplesch at gmail.com>
>> *Subject:* Re: [x3d-public] draft X3D 4.1 prose for font files and
>> libraries
>>
>> I basically had the same questions as Michalis.
>>
>> Comments below.
>>
>>
>> Date: Sat, 1 Mar 2025 05:52:24 +0100
>> From: Michalis Kamburelis <michalis.kambi at gmail.com>
>>
>> As for FontLibrary,
>>
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#FontLibrary
>> : I admit I don't understand this proposal (yet).
>>
>> 1. Where is the FontLibrary actually used? It doesn't seem you can refer
>> to
>> a FontLibrary node in any way. It's also not X3DChildNode, so you cannot
>> just place it in groups.
>>
>>
>> This is a big missing piece.
>> After some thought, I think the idea is to give the X3D browser
>> information on how to render fonts which are referenced in a
>> FontStyle.family field.
>> One option is to think of it not as a Node but as a Statement describing
>> a resource available to the X3D browser in general.
>> Another option is to make it part of WorldInfo as a value for a new
>> WorldInfo.fonts field ?
>> The idea came up as an alternative to a FontStyle.url field, so see below.
>>
>> *response:* See above.
>>
>> 2. The sentence """If present, only the first active font library
>> retrieved
>> from the url list shall be used."""" --- What is the meaning of word
>> "used"
>> in this sentence? Used for what?
>>
>>
>> What is 'active' ? Probably accessible
>>
>> "Used": ?
>>
>> *response: *We were trying to emphasize that only one font file can be
>> loaded by a FontLibrary node. The functionality of an X3D url is
>> unchanged, the first working address in the list is used. This is trying
>> to complement the more general wording in 9.3.2 concisely... Specific
>> wording suggestions always welcome.
>>
>> - X3D 4.1 (draft) Architecture, clause 9 Networking component, 9.3.2
>> X3DUrlObject
>> - "All *url* fields can hold multiple string values. The strings in
>> these fields indicate multiple locations to search for data in the order
>> listed. If the X3D browser cannot locate or interpret the data specified by
>> the first location, it shall try the second and subsequent locations in
>> order until a location containing interpretable data is encountered. X3D
>> browsers only have to interpret a single string. If no interpretable
>> locations are found, the node type defines the resultant default behaviour."
>> -
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#X3DUrlObject
>> X3D Architecture 4.1 draft — ISO/IEC 19775-1:202x — 9 Networking
>> component
>> <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#X3DUrlObject>
>> 9.2 Concepts 9.2.1 URLs, URNs and URIs. A URL (Uniform Resource
>> Locator) is a form of Universal Resource Identifier (URI) described in that
>> specifies a file located on a particular server and accessed through a
>> specified protocol (such as file:, http: or https:).In this document, the
>> upper-case term URL refers to a Uniform Resource Locator, while the
>> italicized lower-case version url refers to ...
>> www.web3d.org
>>
>>
>> 3. """Individual font library files can be used by multiple FontStyle
>> nodes
>> in a scene.""" -- How? FontStyle does not refer to FontLibrary. And I
>> understand in this version, FontStyle would not have its own FontStyle.url
>> field.
>>
>> Did you maybe want to add a field like "SFNode FontLibrary
>> fontLibrary" to FontStyle or Text? Or make FontLibrary a X3DChildNode?
>>
>>
>> That was my first thought as well but see above.
>> A simple way to make a FontLibrary url available to multiple FontStyle
>> nodes is by DEF/USE.
>> A FontStyle.fontLibrary field is preferred over a global scope since it
>> clearly associates a font to a FontStyle/Text.
>> It is better not to have to rely on the family name to identify a font.
>> Having to rely on the family name is more error prone for both the author
>> and the browser.
>>
>> *response: *the cyan text for FontStyle draft prose shows the
>> less-desirable alternative. Have added strikethrough (using html <del>
>> tag) and better description to indicate that we moved url fields from
>> FontStyle to FontLibrary). The cyan alternative is there now for
>> comparison, essentially the prose is the same. Hopefully the draft prose
>> is clearer now, with no duplication of functionality.
>>
>> *response: *We are thinking that if inconsistencies exist between a
>> specified FontStyle family field and the font file, then such cases are
>> best handled on a best-effort basis by browsers without further complex
>> (and possibly contradictory) guidance in specification prose. Perhaps this
>> stance should be a NOTE?
>>
>
>
>
>>
>>
>> 4. A testcase, preferably many testcase(s), explaining the FontLibrary
>> usage (X3D files + intended rendering) would very helpful. (Same goes for
>> the previous proposal actually.) Please provide testcases along with spec
>> prose -- they make the intention more obvious.
>>
>>
>> Including edge cases if possible.
>>
>> *response*: Agreed. We will review the following simple example in our
>> next editors meeting. More examples are welcome from people contributing
>> to this list.
>> EXAMPLE
>>
>> FontLibrary { # example derived from TextHaveFunWithX3D.x3d <https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/dc9111dcd106f1a69d567ceca8f52701/raw/8cdf9764f11e08b5f541dee487fc0811bb0cf927/FontHaveFunWithX3D.x3d>
>> url ["MjQamj1kuP_soQ3o-rysO9Ci_8oJlIUUInI.woff2"
>> "https://fonts.gstatic.com/s/playwritecaguides/v1/MjQamj1kuP_soQ3o-rysO9Ci_8oJlIUUInI.woff2"]
>> }
>> Shape {
>> # ☺ = ☺ smiley face emoticon, and "" means skip a line
>> geometry Text {
>> string [ "Have fun" "with X3D!" "" ":) ☺" ]
>> fontStyle FontStyle {
>> spacing 1.5
>> family=["Playwright_CA_Guides"]
>> justify [ "MIDDLE" "MIDDLE" ]
>> }
>> }
>> }
>>
>>
>> Overall, so far, I admit FontLibrary is confusing to me, I don't know what
>> it means. The previous proposal (extending FontStyle) seems more
>> straightforward -- a few people (including me) had feedback, but it seems
>> that we all "got the intention" of FontStyle.url correctly, we just
>> pointed
>> some things to improve in wording.
>>
>>
>> One advantage of a FontLibrary (or perhaps just 'Font') node would be
>> DEF/USE.
>>
>> As mentioned multiple times, the spec. should include language that the
>> FontStyle.style field may be ignored if a FontLibrary url is accessible as
>> in most cases that url will only provide data for one specific style..
>>
>> Regards, -Andreas
>>
>> *response: *the presence of the css style field might add a whole new
>> level of sophistication and possible edge cases.
>>
>> This again sounds like a rationale for a NOTE in the specification
>> specifically pointing out that browsers have latitude to handle ambiguous
>> cases before falling back to default font... Might be obvious/redundant or
>> might be helpful.
>>
>> Hope these responses help us converge, again thanks for together thinking
>> things through. v/r Don
>>
>>
>> pt., 28 lut 2025 o 19:56 Brutzman, Donald (Don) (CIV) via x3d-public <
>> x3d-public at web3d.org> napisa?(a):
>>
>> > Thanks everyone for responses, implementation improvements, technical
>> > details, and many insights.
>> >
>> > First positive takeaway: WOFF File Format 2.0 is the clear preference
>> to
>> > WOFF 1.0.
>> >
>> > WOFF File Format 2.0, W3C Recommendation, 08 August 2024
>> >
>> > - "Abstract. Based on experience with WOFF 1.0, which is widely
>> > deployed, this specification was developed to provide improved
>> compression
>> > and thus lower use of network bandwidth, while still allowing fast
>> > decompression even on mobile devices. This is achieved by combining a
>> > content-aware preprocessing step and improved entropy coding,
>> compared to
>> > the Flate compression used in WOFF 1.0."
>> > - https://www.w3.org/TR/WOFF2
>> >
>> > Clearly, from recent excellent emails, there are many
>> implementer-specific
>> > issues and interactions when adding font files that are good to know
>> about,
>> > but don't necessarily need to be expressed in an X3D model (or the X3D
>> > Architecture specification).
>> >
>> > Dick and I worked further today to assess whether separation of font
>> files
>> > from FontStyle node into a FontLibrary node was the preferred to
>> represent
>> > this information in an X3D model. We also repeated WOFF
>> Recommendation's
>> > use of term "collection" as part of a *FontLibrary *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://outlook.office.com/mail/id/AAkALgAAAAAAHYQDEapmEc2byACqAC%2FEWg0AN5ikByHYYkeveIfklhUi1gAG%2Blh21AAA?nativeVersion=1.2025.219.400#FontStyle>
>> and
>> > ScreenFontStyle
>> > <https://outlook.office.com/mail/id/layout.html#ScreenFontStyle>
>> nodes.
>> >
>> > FontLibrary node pros (meaning separation of font files from FontStyle
>> > node):
>> >
>> > - Keeps existing (and fairly complex) FontStyle implementations
>> > unchanged
>> > - Separation of loading and presentation functionality between two
>> > nodes
>> > - FontLibrary simply adds to the selection of fonts available, and
>> > retains emphasis of *family *and *style *fields within a given
>> > FontStyle node.
>> > - If separate font files redefine a given family (with the same
>> name),
>> > then addition of *enabled *field might allow authors to determine
>> > which of them is relevant. However *enabled *field can be considered
>> > redundant (since changing url has same effect).
>> > - Alternative approach to use of an *enabled *field, we might also
>> > need to add a sentence such as
>> > - "If a font family is redefined by multiple FontLibrary nodes, then
>> > the first defined family is used."
>> > - (or we can remain silent and let browser implementations sort
>> > that out)
>> >
>> > FontLibrary node cons (meaning bundle all url functionality in
>> FontStyle):
>> >
>> > - Closer coupling of *family *field and font files themselves, recent
>> > email dialog indicates that sometimes the font file simply overrides
>> the
>> > family field...
>> > - We do not want to change any defined functionality for *family*
>> and *style
>> > *fields, they still seem correct in X3D Architecture and no suitable
>> > changes yet seen.
>> > - No need for *enabled *field.
>> >
>> > Our current opinion is that FontLibrary provides a superior approach to
>> > continued growth of FontStyle node. To facilitate comparison and
>> review,
>> > current draft has proposed FontLibrary prose in yellow, and alternate
>> > (not accepted) FontStyle alternative in cyan.
>> >
>> > - 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
>> > X3D Architecture 4.1 draft ? ISO/IEC 19775-1:202x ? 15 Text component
>> > <
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD/Part01/components/text.html#FontLibrary
>> >
>> > 15.2.2.4 Language. The language field specifies the context of the
>> > language for the text string in the form of a language and a country
>> in
>> > which that language is used. Both the language and the country are
>> > specified using the language tags defined in which may specify only a
>> > country (using the three-character codes defined in ISO 3166) or
>> both a
>> > language (using the two-character codes ...
>> > www.web3d.org
>> >
>> >
>> > Additional questions to ponder, further insights welcome:
>> >
>> > - Our impression of the term 'webfont' is that it is simply a generic
>> > term, not a standard or specification per se, and often employed to
>> > reference WOFF. Is that correct?
>> >
>> > - Font files tend to be large. Might there ever be a use case where
>> > an author chooses to define a font as source text in the url field?
>> We
>> > have some precedent for this in Script url and (sorta) PixelTexture.
>> > Nevertheless font definitions are also convoluted and (perhaps
>> notoriously)
>> > difficult to parse. Of note is that WOFF2 specifically is designed
>> for
>> > effective binary compression. Our inclination so far is to not
>> describe
>> > (or encourage) definition of the font within an X3D model. YMMV
>> (though we
>> > doubt it). Much better authoring approach is to use any of many
>> conversion
>> > tools that might credibly update a legacy font into WOFF2.
>> >
>> > Thanks everyone for leaning forward on this, looking ahead to continuing
>> > discussion.
>> >
>> > Have fun with font library collections for X3D models! ?
>> >
>> >
>> > 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
>> Brutzman,
>> > Donald (Don) (CIV) via x3d-public <x3d-public at web3d.org>
>> > *Sent:* Wednesday, February 26, 2025 5:39 PM
>> > *To:* X3D <x3d-public at web3d.org>
>> > *Cc:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> > *Subject:* Re: [x3d-public] draft X3D 4.1 prose for font files and
>> > libraries
>> >
>> > Dick and I worked on suggested prose for X3D 4.1 with details continuing
>> > in Mantis 1490 below.
>> >
>> > Review request:
>> >
>> > - X3D 4.1 Architecture (draft), 15 Text component, 15.4.1 FontStyle
>> > -
>> >
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/text.html#FontStyle
>> >
>> > Improvements:
>> >
>> > - Include all X3DURLObject fields,
>> >
>> > SFTime [in,out] autoRefresh 0.0 [0,?)
>> > SFTime [in,out] autoRefreshTimeLimit 3600.0 [0,?)
>> > SFString [in,out] description ""
>> > SFBool [in,out] load TRUE
>> > MFString [in,out] url [] [URI]
>> >
>> > - Decided to NOT overload functionality of *family * field by adding
>> > file names (sorry Holger! adjusting your implementation will likely
>> be
>> > simple in comparison)
>> >
>> > - New prose:
>> >
>> > The *url* field is optional and can refer to a relative or online
>> address
>> > for a font library that contains one or more font definitions. An empty
>> > *url* list indicates that the default set of fonts provided by the
>> > browser are used. If present, only the first active font library
>> retrieved
>> > from the *url* list shall be used. Individual font library files can be
>> > used by multiple FontStyle nodes in a scene. Each font file only needs
>> to
>> > be loaded once per session.
>> > X3D browsers shall support WOFF (MIME type application/x-font-woff)
>> (see W3C
>> > WOFF File Format
>> > <
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#W3C_WOFF
>> >).
>> > Support for the OpenType file format (MIME type
>> > application/x-font-opentype) (see OpenType Specification
>> > <
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/bibliography.html#OPENTYPE
>> >)
>> > and TrueType file format (MIME type application/x-font-truetype) (see
>> ISO/IEC
>> > 14496-22 Open Font Format
>> > <
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/references.html#I14496_22
>> >)
>> > is also recommended.
>> > Security, licensing, and copyright/usage permissions are handled via the
>> > exposure of a font file itself.
>> > Support for the *autoRefresh*, *autoRefreshTimeLimit*, and *load*
>> fields is
>> > optional.
>> > More details on the *autoRefresh*, *autoRefreshTimeLimit*,
>> *description*,
>> > *load*, and *url* fields are contained in 9.2.1 URLs, URNs and URIs
>> > <
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/components/networking.html#URLs
>> >
>> > .
>> > Looking it over, adding more functionality to FontStyle node seems to be
>> > unwise. Dick has an excellent proposal:
>> > TODO alternative approach: move all new functionality into a separate
>> > *FontLibrary* node to avoid complicating FontStyle further. This also
>> > offers the ability to succinctly load multiple font libraries in a given
>> > scene. The expense of defining a new node for X3D is offset by clearer
>> > distinction between X3D 4.0 and 4.1, also simplifying model content
>> > significantly.
>> > Feedback is welcome.
>> > Leaving existing FontStyle implementations alone probably avoids many
>> > unintended side effects. First law of engineering: "If it ain't broke,
>> > don't fix it."
>> >
>> > Thanks for all review. It feels like we are finally converging on a
>> > straightforward approach to valuable future capabilities.
>> >
>> > Have fun with X3D fonts! ?
>> >
>> >
>> > 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:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> > *Sent:* Monday, February 24, 2025 9:32 AM
>> > *To:* X3D <x3d-public at web3d.org>
>> > *Cc:* Holger Seelig <holger.seelig at yahoo.de>
>> > *Subject:* Re: [x3d-public] Open dyslexic and/or (unfortunately)
>> > comicsans fonts; draft X3D 4.1 prose for font files and libraries
>> >
>> > Wow, really super Holger! ?
>> >
>> > There was a conversation about this on x3d-public a few years back... We
>> > committed to adding it in X3D 4.1 and (if I recall correctly) also noted
>> > that adding a url field might enable usage of larger font files.
>> >
>> > I've attempted to capture this candidate specification change in a
>> Mantis
>> > issue. All review, feedback, and improvements are always welcome.
>> >
>> > - Mantis 1490 FontStyle handling of font files and font libraries
>> > - https://mantis.web3d.org/view.php?id=1490
>> >
>> > Description.
>> > A goal for X3D 4.1 is use of font files in FontStyle (see Mantis 0001464
>> > <https://mantis.web3d.org/view.php?id=1464>).
>> >
>> > Addition of individual-font files might be accomplished by listing the
>> > font file name in the FontStyle 'family' field.
>> >
>> > Referencing different fonts in a single combined font library file may
>> > require an additional field, for example 'url'. In general the use of a
>> > font library may be preferred, but repeatedly run-time retrieval of a
>> font
>> > library is not desirable, since the file might be quite large and rarely
>> > changing. This might be noted in the specification prose, e.g.
>> >
>> > - "MFString [in,out] url [] [URI]"
>> > - "The family field may list a specific font file. A font listed in the
>> > family field may be provided by a corresponding font library."
>> > - "The url field may refer to a font library. Font libraries can be used
>> > by multiple FontStyle nodes in a scene and need only be loaded once per
>> > session."
>> >
>> > Support levels: add "Level 2, FontStyle, support for font files in
>> family
>> > field and support for font libraries via url field ."
>> >
>> > Security, licensing, and copyright/usage issues are handled via the
>> > exposure of the font file itself. If retrievable (locally or online)
>> then
>> > proper access is presumably handled separately.
>> >
>> > Additional information.
>> > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.1 FontStyle
>> > -
>> >
>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#FontStyle
>> >
>> > - X3D 4.1 (draft) Architecture, 15 Text component, 15.4.2 Text
>> > -
>> >
>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#Text
>> >
>> > - X3D 4.1 (draft) Architecture, 15 Text component, 15.5 Support levels
>> > -
>> >
>> https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/text.html#SupportlLevels
>> >
>> > Have fun with X3D Text! :)
>> >
>> >
>> > 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:* Monday, February 24, 2025 2:48 AM
>> > *To:* X3D <x3d-public at web3d.org>
>> > *Cc:* Holger Seelig <holger.seelig at yahoo.de>
>> > *Subject:* Re: [x3d-public] Open dyslexic and/or (unfortunately)
>> > comicsans fonts
>> >
>> > With X_ITE you can use a URL in the family field of a FontStyle node to
>> > specify a path to a custom font file. Provided you have one of these
>> fonts,
>> > it should be very easy:
>> >
>> > <?xml version="1.0" encoding="UTF-8"?>
>> > <!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 4.0//EN" "
>> > https://www.web3d.org/specifications/x3d-4.0.dtd">
>> > <X3D profile='Interchange' version='4.0' xmlns:xsd='
>> > http://www.w3.org/2001/XMLSchema-instance'
>> xsd:noNamespaceSchemaLocation='
>> > https://www.web3d.org/specifications/x3d-4.0.xsd'>
>> > <head>
>> > <component name='Text' level='1'/>
>> > </head>
>> > <Scene>
>> > <Transform DEF='Text'>
>> > <Shape>
>> > <Appearance>
>> > <Material/>
>> > </Appearance>
>> > <Text
>> > string='"3D Text"'>
>> > <FontStyle
>> > family='"path/to/your/font.otf", "SERIF"'/>
>> > </Text>
>> > </Shape>
>> > </Transform>
>> > </Scene>
>> > </X3D>
>> >
>> > Supported File Formats:
>> >
>> >
>> https://create3000.github.io/x_ite/components/text/fontstyle/#supported-file-formats
>> >
>> > Best regards,
>> > Holger
>> >
>> > --
>> > Holger Seelig
>> > Leipzig, Germany
>> >
>> > holger.seelig at yahoo.de
>> > https://create3000.github.io/x_ite/
>> >
>> > Am 24.02.2025 um 11:09 schrieb John Carlson via x3d-public <
>> > x3d-public at web3d.org>:
>> >
>> > If someone knows how change the fonts of the standards to OpenDyslexic
>> or
>> > ComicSans, that might be a great accessibility experiment.
>> > _______________________________________________
>> > x3d-public mailing list
>> > x3d-public at web3d.org
>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>> >
>> >
>> > _______________________________________________
>> > 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/20250301/db01b350/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>> ------------------------------
>>
>> End of x3d-public Digest, Vol 191, Issue 133
>> ********************************************
>>
>>
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
--
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20250302/7dd19dff/attachment-0001.html>
More information about the x3d-public
mailing list