Add STIX fonts
STIX fonts project page
Background: Currently LibO ships the opensymbol fonts, used e.g. for greek and mathematical notation. To quote from the stix page: "The mission of the Scientific and Technical Information Exchange (STIX) font creation project is the preparation of a comprehensive set of fonts that serve the scientific and engineering community in the process from manuscript creation through final publication, both in electronic and print formats." Sounds like a perfect addition to LibO.
Not an easyhack, needs license clarification (non-LGPL) and most distros will want to ship this as an external package. Probably only for Windows anyway?
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
A highlight of the "SIL Open Font License 1.1" is:
The OFL allows the licensed fonts to be used, studied, modified and
redistributed freely as long as they are not sold by themselves. The
fonts, including any derivative works, can be bundled, embedded,
redistributed and/or sold with any software provided that any reserved
names are not used by derivative works. The fonts and derivatives,
however, cannot be released under any other type of license. The
requirement for fonts to remain under this license does not apply
to any document created using the fonts or their derivatives.
Dear bug submitter!
Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.
To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.
The NEEDINFO queried the license, and Comment 3 was an attempt to address this.
Good point :-) the ux-advise guys have been asked to review our default bundled fonts situation, and I guess it'd be good to feed this bug into that process.
Thanks for re-opening !
Just changed the platform as it isn't really a windows issue...
Sorry, overead that - Status set to NEW
Created attachment 89111 [details]
FontForge screenshots showing STIX-Regular and STIXMath-Regular.
I would be concerned about including the STIX fonts in LO as they contain many invalid uses of code points. Where Unicode does not support a particular character the Private Use Area (U+E000..U+F8FF), Supplemental Private Use Area-A (U+F0000..U+FFFFD), and Supplemental Private Use Area-B (U+100000..U+10FFFD), can be used to encode 6400, 65534, and 65534 characters respectively.
In v1.1.1-Word the STIX fonts include these invalid non-Unicode code points:
- STIX-Bold, 63 glyphs, 0x110000..0x11003c
- STIX-BoldItalic, 2 glyphs, 0x110000..0x110001
- STIX-Italic, 2 glyphs, 0x110000..0x110001
- STIX-Regular, 125 glyphs, 0x110000..0x11007c
- STIXMath-Regular, 926 glyphs, 0x110000..0x11039d
The Bold, BoldItalic, Italic, and Regular fonts all make partial use (~100-350 glyphs) of the Private Use Area, while the Math font does not use this area at all (attached screenshots are indicative). There are also some basic errors reported by FontForge.
While I can appreciate the need for a greater range of math glyphs, pushing non-Unicode fonts of this nature into the LO user-base would seem potentially problematic and at the very least require *extensive* testing i.e., printing, PDF/file-embedding, interop, etc. The current OpenSymbol font by comparison, although less extensive, does not contain any errors or invalid encodings.
You will be surprised to know that our own OpenSymbol font uses PUA for characters *already* in Unicode. The STIX Word fonts do not use PUA at all, actually (FontForge is misleading you), those glyphs are not assigned any code points at all and are internal to the fonts.
The STIX Regular font seems to use PUA, though. But those are not glyphs that we are interested in, anyway.
Khaled thanks for your responses. Apologies if my comment / concern was unfounded.
(In reply to comment #13)
> You will be surprised to know that our own OpenSymbol font uses PUA for
> characters *already* in Unicode.
Well, perhaps disappointed rather than surprised ;) Not ideal, but the PUA is available to include anything so I guess not awful either.
> those glyphs are not assigned any code points at all and are internal to the fonts.
I wasn't as clear as I could have been. I was worried these additional characters at the large hexadecimal offset were the required symbols. I see now they appear to be scaled variants of existing (encoded) glyphs. At least that is what they look like to me. Thanks again and sorry for the noise.
(In reply to comment #15)
> > those glyphs are not assigned any code points at all and are internal to the fonts.
> I wasn't as clear as I could have been. I was worried these additional
> characters at the large hexadecimal offset were the required symbols. I see
> now they appear to be scaled variants of existing (encoded) glyphs. At least
> that is what they look like to me. Thanks again and sorry for the noise.
These unencoded glyphs are not accessed directly thus has no separate code points, instead they are used by capable layout applications when e.g. a large glyph is necessary (a display big operator, large parenthesis) etc. instead of linear scaling of the base glyphs (as Math does now, which is aesthetically ugly). It would be a huge improvement to be able to do this in Math, but we are nowhere near this.
In reply to comment 3: Although it's not ideal in the abstract, a lot of font licenses work this way, and this specific license is both DFSG compatible and FSF approved
In reply to comment 10: Despite appearances, this is a Windows only issue
- OSX bundles the STIX fonts itself since 10.7
- All major Linux distributions provide a package for the STIX fonts, so it would be inappropriate to bundle another copy there
The only real remaining question is whether it would be appropriate for LibreOffice to bundle its own copy on Windows
Platform set -> Windows
Severity set -> enhancement
Liberation font project has a request for adding math fonts.
If they are implemented, we can also try to bundle that, and this bug could become invalid.