Possibility of using WorldWeatherSymbols in Metanorma

[ronaldtse]

@chris-little at the Met Office raised the issue of using https://github.com/OGCMetOceanDWG/WorldWeatherSymbols in Metanorma documents during the OGC DocTeam session.

It was said that we can either refer to a Unicode private plane (if a font supporting these symbols is included, such as from https://github.com/Unidata/MetPy), or we support their symbols.

I wonder if there is an easy way of supporting new symbols/icons.

Thoughts @opoudjis ?

[chris-little]

Ron,
The correct Unicode terminology is the 'Private Usea Area', preferably in the Basic Multilingual Plane. Not many apps support the full multiplane Unicode as described in ISO10646.
The six thousand or so codes points of the PUA in the Basic Multilingual Plane are (U+E000 to U+F8FF) and are more than enough for all the interntionally standardised WMO and ICAO weather symbols.
The other two PUAs are 64K in size each. HTH, Chris

[opoudjis]

I'm not delighted about using the PUA, because that really presupposes that all recipients of the document are using the self-same font. But even PUA characters are cleaner than schlepping around icons (and in fact, fonts like FontAwesome increasingly realise icons as Unicode characters instead of GIFs anyway).

So, yes, we can support PUA fonts readily; but (a) we would have to enforce use of the corresponding font in OGC Metanorma output, and (b) we would have to make sure that Word and PDF do not balk at any Astral Plane characters (over U+10000). @chris-little is proposing to use Plane 0, so there should be no issue there.

("Astral Plane" support (https://en.wikipedia.org/wiki/Astral_plane_(disambiguation): "an alternative name for planes 1–16 of the Unicode standard"), which Chris refers to above as "full multiplane Unicode", is a lot better than it used to be; Word now deals with it for example, as do modern browsers. But it still not perfect: online texteditors for example often skip them. It is after all the dumping ground for scripts not in current use, like Egyptian hieroglyphics: it is by design low priority.)

All that said: it may well be desirable to limit the custom font to just those icons and not to enforce them throughout the document. That would most readily be done in postprocessing: detect all instances of the PUA characters, and wrap them in a CSS style enforcing the use of the particular font for just those character spans.

[opoudjis]

@ronaldtse Is there an action here? If the ticket is assigned to me, it does need to have a priority.

[ronaldtse]

It's certainly possible to implement support for a private code point for a particular gem, but the solution would be allowing to address a codepoint in a particular "genre" of font.

Currently we don't seem to have commitment in using these weather symbols, so let's postpone it for now (feel free to correct if I'm wrong @chris-little 😉 ).

(unassigning it for now)

[chris-little]

@ronaldtse I have no problem with that. Private Use Areas are undoubtedly not a success of Unicode!

[opoudjis]

@chris-little is there any change in the commitment to using the weather symbols?

[chris-little]

@opoudjis No we still think it a good idea to get the WMO/ICAO standardised weather symbols into Unicode to make them much more readily useable, rather than having to invoke computer graphics packages. It also fits with the strategy that eventually weather specific applications will be replaced by generic GIS applications, perhaps with a 'weather style sheet', and then perhaps generic GIS apps being replaced by position-aware Web browsers.
Apologies for not having had any spare time to push this recently.

[ronaldtse]

For the record the MetPy font for these symbols is here: https://github.com/Unidata/MetPy/tree/cee9d4de5bc37a4cd2efc381f0a08f3a53d00940/metpy/plots/fonts

To use these symbols we will need to have a textual way of referring to a particular character code of a particular font (the MetPy font here).

e.g.

sym:[wws,icao:SevereTurbulence]

To show https://github.com/OGCMetOceanDWG/WorldWeatherSymbols/blob/master/symbols/ICAO_SigWx/WeatherSymbol_ICAO_SevereTurbulence.svg.

Or if there is a URN for the symbols we can have something like:

sym:[wws,urn:ogc:symbols:wws:icao-severe-turbulence]

[chris-little]

@opoudjis To answer your earlier question

any change in the commitment to using the weather symbols

Well, we are still forecasting weather around the world in 193 countries using these symbols, so that use is not changing. The argument for making them available in Unicode (whether PUA or not) has not changed. Whether they are needed in Metanorma is not for me to say.
Another argument is that 'symbols' are now much more prevalent in Unicode systems than a few years ago, in spite of their committment to 'glyphs', so having the symbols readily available in Unicode should make it easier to get the weather and aviation symbols into GIS systems, reducing the need for custom weather apps.

I certainly see merit in pursuing this from my point of view, as, for example, we have used 3D Augmented Reality headsets to teach meteorology, and easily ingesting those weather symbols should lower the cost of developing those teaching aids.

[chris-little]

For the record the MetPy font for these symbols is here: https://github.com/Unidata/MetPy/tree/cee9d4de5bc37a4cd2efc381f0a08f3a53d00940/metpy/plots/fonts
To use these symbols we will need to have a textual way of referring to a particular character code of a particular font (the MetPy font here).
e.g. sym:[wws,icao:SevereTurbulence]
To show https://github.com/OGCMetOceanDWG/WorldWeatherSymbols/blob/master/symbols/ICAO_SigWx/WeatherSymbol_ICAO_SevereTurbulence.svg.
Or if there is a URN for the symbols we can have something like:
sym:[wws,urn:ogc:symbols:wws:icao-severe-turbulence

@ronaldtse The SVG weather symbols used the corresponding WMO code figures as unique IDs, but these are not readily understandable by non-experts. There should be enough text in each symbol's SVG/XML to construct a unique, shortish, English-like identifier.

HTH, Chris

[ronaldtse]

A hark back to the past: with the implementation of metanorma/metanorma-standoc#618 , we are now able to handle custom fonts (as long as the font is supported in Fontist). We can technically use the MetPy symbols (https://github.com/Unidata/MetPy/blob/main/src/metpy/plots/fonts/wx_symbols.ttf) in Metanorma.

The challenge is that the MetPy font makes heavy use of the Unicode Private Use Area, so that the user needs to know the Unicode code point of the character to use it in Metanorma:

Now, this has gotten me thinking that perhaps we should support "Symbol Libraries", which are actually not so different from reusing Terms/Concepts from Termbases:

• IEC provides a symbol library, e.g. https://symbols.demo.paneron.org/symbols/
• IEC Electropedia contains entries that have symbols (or international symbols)

If we treat Symbols as generic concepts, and that we have a way to import/refer to concept libraries, then this will be extremely useful.

I have filed fontist/formulas#131 for adding the MetPy wx_symbols.ttf font in Fontist, which allows the font to be used in Metanorma. We will need to create a separate page for users on how to use the font since it involves specific Unicode code points.

[opoudjis]

And we can specify arbitrary fonts on text spans:

https://www.metanorma.org/author/topics/document-format/text/#css-declarations

[css font-family:"Noto Sans Canadian Aboriginal"]#ᓀᐦᐃᔭᐍᐏᐣ#

@ronaldtse what remains to be actioned here?

[ronaldtse]

[css font-family...] does not apply to PDF and Word output...

[opoudjis]

[css font-family...] does not apply to PDF and Word output...

I was wrong, the CSS does travel through to the Word, and there is no intrinsic reason why it cannot be parsed in the PDF.

[Intelligent2013]

As I note in https://github.com/metanorma/pdfa-iso-32000-2/issues/11#issuecomment-1688240475, we need to specify the font name Noto Sans Canadian Aboriginal in the document attribute :fonts: additionally, for the installation by fontist (but fontist(or metanorma) doesn't pass the font name for the manifest generation).

[ghobona]

OGC Staff briefed on 2023-09-04.

[ronaldtse]

I was wrong, the CSS does travel through to the Word, and there is no intrinsic reason why it cannot be parsed in the PDF.

PDF processing should never be parsing CSS. The solution is at:

• Font specification of inline/block text (not css font-family) metanorma#339

[opoudjis]

The Semantic XML solution is in place. @Intelligent2013 can I confirm that you still cope with <span style="font-family:&quot;Code 2000&quot;">? If so, any code change in Presentation XML to deal with inline styling in a more granular way can be deferred, and this ticket can be closed.

[Intelligent2013]

@Intelligent2013 can I confirm that you still cope with <span style="font-family:&quot;Code 2000&quot;">?

@opoudjis yes. But, please note, that we need to specify :fonts: Code 2000 in the document.adoc additionally, and there is the non-resolved issue metanorma/metanorma#311 regarding passing :fonts: list into fontist manifest.

[opoudjis]

Ok. Since those are pre-existing issues, closing this issue. I've mentioned in documentation the need for :fonts:

[ronaldtse]

@Intelligent2013 how come the font is called “Code 2000”?

[opoudjis]

It is an example of a font that implements Klingon in the PUA.