space: it seems, LibreOffice 3.4 breaks the lines at spaces before Graphite rendering, not only at line ends and character formatting boundaries. Now space normalization (for small caps, superiors, all caps, non French spacing between sentences), Italic correction, hanging punctuation don't work with the Graphite 2 integration.
#: For hanging punctuation and for other tasks it would be better to use the real line boundary mark (#) in the Graphite rules, but LibreOffice hasn't supported, yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It was a conscious choice to no longer support line end contextuals. In addition, the adding of segment caching to the libo integration means that runs are broken on spaces. Using graphite to be TeX is not really what it was designed for. Is there an orthographic need for line end or space based contextuals?
Proposing this bug be closed with rejected
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Line end contextuals and space replacements are important competitive features for LibreOffice. Microsoft Office has already supported contextual alternates (see http://office.microsoft.com/en-us/word-help/opentype-options-in-the-font-dialog-box-HA101809106.aspx\), a basic feature of OpenType. Segmentation has to pass the line end/space boundary information + the spaces (one side) to the Graphite engine.
By the way, this is not only for pure typography, eg. one of the new features of Linux Libertine G (contextual replacement of ligature f_i to (f.short i), when the hyphenated word part contains only a fi-ligature) is a solution for a hyphenation rule described in a Hungarian orthography book (Helyesírás, Osiris).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, this is a known regression. We do have plans to fix it, This involves: 1) adding a capability to the compiler to spot that spaces are being used in rules, so that 2) the engine can inhibit the use of the segment caching which is based around spaces.
As to line end contextuals. Can you explain to my slow brain how line end contextuals gets you hanging punctuation?
If this is the only contextualisation needed, I wonder if we can fix this by marking the trailing punctuation as whitespace for line break calculations. For that we would need some kind of 'treat as whitespace' type attribute on a glyph that could be queried by the line breaker.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think, hanging punctuation of LibreOffice/Linux Libertine G doesn’t need any extra development, because it uses contextual substitution of the punctuation marks to hanging alternatives. These alternative glyphs contain the same marks with different width, so they will hang. Hanging is never 100% and it depends from the glyph. (Linux Libertine G uses similar values which used in pdfTeX, see Hàn Thế Thành's thesis: http://www.pragma-ade.com/pdftex/thesis.pdf\).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Test files
Also in the positioning rules.
space: it seems, LibreOffice 3.4 breaks the lines at spaces before Graphite rendering, not only at line ends and character formatting boundaries. Now space normalization (for small caps, superiors, all caps, non French spacing between sentences), Italic correction, hanging punctuation don't work with the Graphite 2 integration.
#: For hanging punctuation and for other tasks it would be better to use the real line boundary mark (#) in the Graphite rules, but LibreOffice hasn't supported, yet.
It was a conscious choice to no longer support line end contextuals. In addition, the adding of segment caching to the libo integration means that runs are broken on spaces. Using graphite to be TeX is not really what it was designed for. Is there an orthographic need for line end or space based contextuals?
Proposing this bug be closed with rejected
Line end contextuals and space replacements are important competitive features for LibreOffice. Microsoft Office has already supported contextual alternates (see http://office.microsoft.com/en-us/word-help/opentype-options-in-the-font-dialog-box-HA101809106.aspx\), a basic feature of OpenType. Segmentation has to pass the line end/space boundary information + the spaces (one side) to the Graphite engine.
By the way, this is not only for pure typography, eg. one of the new features of Linux Libertine G (contextual replacement of ligature f_i to (f.short i), when the hyphenated word part contains only a fi-ligature) is a solution for a hyphenation rule described in a Hungarian orthography book (Helyesírás, Osiris).
More information about start and end of line flags: http://openoffice.org/bugzilla/show_bug.cgi?id=111272
Yes, this is a known regression. We do have plans to fix it, This involves: 1) adding a capability to the compiler to spot that spaces are being used in rules, so that 2) the engine can inhibit the use of the segment caching which is based around spaces.
As to line end contextuals. Can you explain to my slow brain how line end contextuals gets you hanging punctuation?
If this is the only contextualisation needed, I wonder if we can fix this by marking the trailing punctuation as whitespace for line break calculations. For that we would need some kind of 'treat as whitespace' type attribute on a glyph that could be queried by the line breaker.
I'm very glad of your effort, thanks for it.
I think, hanging punctuation of LibreOffice/Linux Libertine G doesn’t need any extra development, because it uses contextual substitution of the punctuation marks to hanging alternatives. These alternative glyphs contain the same marks with different width, so they will hang. Hanging is never 100% and it depends from the glyph. (Linux Libertine G uses similar values which used in pdfTeX, see Hàn Thế Thành's thesis: http://www.pragma-ade.com/pdftex/thesis.pdf\).