Re: Windows / font / text futures ...
Apologies for reviving this thread rather than spinning anew, think this is germane. A year on and Khaled's clean-up of the the HarfBuzz common layout implementation is mostly done, including a bunch of work that was needed for font handling. Thanks! But there are a few warts with the results on Windows. And at 5.3.2.2, for Windows users unable to use OpenGL, font quality to canvas and in the UI is "rough" compared to GDI calls used through 5.2 (or even 5.3.1). Some BZ font rendering issues of note ref'd below. So, where next? Can the DirectWrite rendering implementation actually be improved? Maybe in conjunction with the refactoring for floating point positioning? =-ref-= tdf#106990 <https://bugs.documentfoundation.org/show_bug.cgi?id=106990> --font rendering got worse looking in 5.3.2.2 tdf#107090 <https://bugs.documentfoundation.org/show_bug.cgi?id=107090> -- Text is poorly rendered to presentation mode canvas -- View this message in context: http://nabble.documentfoundation.org/Windows-font-text-futures-tp4177355p4212514.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
I'm replying from the digest so the thread may mess up. So much good stuff to agree with. I think it's clear that there is a difference between the process of getting glyphs on a screen (rendering) and working out which glyphs should go where at the run level (shaping) and at the paragraph level (layout). They each have their own issues. On rendering. I don't think it matters too much which approach one takes to get glyphs on the screen. Freetype is nice and cross platform but may not be the quickest library on the shelf. Local rendering is costly to maintain but can give you various goodies. I'm no expert here and I get very confused when I look at firefox. But then I am thinking that all applications in this space are carrying a fair amount of legacy baggage. Onto something I think I know more about: shaping. As one of the poor fools who has tried to create a SalLayout subclass (for Graphite), I agree that the current model is very broken and just about holds together. The layer violations are embarrassing and confusion abounds. I agree that we should come up with a good API for vcl and stop sw digging around in the mud. Personally, I think kashida insertion is the job of something like harfbuzz. In fact justification is something the font wants to get involved in (do we expand a ligature here? use glyph ductility here? limit the amount of inter base glyph here and balance it against what is given to the space, and so on and so fifth). Justification is too complicated to be done by the application, it requires too much script knowledge. Better to have the application negotiate with the font to allocate an overall expansion/contraction for a run and let the shaper do the heavy lifting from there. harfbuzz is nice in that it provides a plugin mechanism, in effect, to allow other shapers to get involved, but provides a single interface for the application. This is good. I would be happy for harfbuzz to win the day and have Graphite accessed under that, so long as we do it right ;) As to floating point. Yes there are system differences, but they are so minor in this game as to be completely ignorable. I took care when doing my collision avoidance stuff, that does lots of maths, with floats rather than doubles, and found that once I got the thing overall correct, the need for rounding management was much less than I thought and that once you take an int(aFloat) the differences are gone between systems. While floats are used for shaping, it's more to save the effort of fixed point integer maths which is fiddly and with a modern CPU, much slower than floating point. If rounding were an issue, we would switch to doubles in a flash. No such need has been found. The need for good fidelity in shaping across platforms is about line breaking, primarily and the results are generally good, certainly much better than native shaping, which almost guarantees you are going to be frustrated. I think we have to go with consistent shaping across all platforms if we want documents to have any hope of laying out the same across different platforms. When it comes to layout, there are lots of fun things that can be done. The trendy direction at the moment is to implement the TeX paragraph layout algorithm and android has minikin which we could probably leverage to help there. Why do I think we need to see change? Well, when it takes 20+ reshapings of a paragraph to get it onto the screen (as someone measured), one has to ask whether something might be wrong. Yes shaping is cheap, at least for simple Latin, but these things add up, and once you get onto Indic or Arabic shaping, they multiply up quite a long way. In the modern battery saving world, it must be possible to save doing quite so much redundant work? Yes all this will take quite a lot of work to get right. The question is whether we have the will to make it right. Thanks for listening! Yours, Martin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On 07.03.2016 22:39, Norbert Thiebaud wrote: > I do think that the first step is to push the layouting tweaks/hacks > out of writer and into vcl itself, > make dxarray read-only, > and _then_ we are free to implement/improve stuff in vcl as desired. but wouldn't that mean refactoring 5 VCL SalLayout subclasses? if there were only one harfbuzz layout class it would be easier :) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On 2016/03/08 10:42 AM, Stephan Bergmann wrote: While this is an issue for actual math on potentially very large or very small numbers (which is, I assume, why calc is careful with it), and an issue for games with large 3D worlds, it can hardly be an issue for the magnitudes of numbers we deal with in the font rendering paths. Are you sure? TeX for example is very careful with its calculations to ensure consistent layout across implementations, regardless of available floating-point functionality. Given that TeX was written before there was an IEEE floating point standard, and in an era where floating point hardware was not even universally available, its choice is not surprising. But that should not restrict our options today :-) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On 03/07/2016 06:08 PM, Noel Grandin wrote: On 7 March 2016 at 18:22, Thorsten Behrens wrote: You're getting different rounding even depending on the flags your OS (or driver that happens to be in your process) sets. Seriously - I'm too lazy to dig out references, but consider floating point math to be inherently non-similar from one box to the next, *unless* you're extremely careful across the entire calculation chain (which is the case in Calc). While this is an issue for actual math on potentially very large or very small numbers (which is, I assume, why calc is careful with it), and an issue for games with large 3D worlds, it can hardly be an issue for the magnitudes of numbers we deal with in the font rendering paths. Are you sure? TeX for example is very careful with its calculations to ensure consistent layout across implementations, regardless of available floating-point functionality. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On Mon, Mar 7, 2016 at 5:20 PM, Chris Sherlock wrote: > > Do you have any code pointers where writer modifies the layout? sw/source/core/txtnode/fntcache.cxx Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
Not a criticism, when I was trying to follow the code I was feeling the same way! Your comment was very helpful, and I went from frustrated to amused :-) Chris Sent from my iPhone > On 8 Mar 2016, at 10:35 AM, Khaled Hosny wrote: > >> On Tue, Mar 08, 2016 at 10:18:47AM +1100, Chris Sherlock wrote: >>> On 8 Mar 2016, at 5:38 AM, Khaled Hosny wrote: >>> On Mon, Mar 07, 2016 at 02:04:41PM +, Michael Meeks wrote: Hi Thorsten, I missed your mail; please do maintain the CC if you want a prompt reply =) On Fri, 2016-03-04 at 00:43 +0100, Thorsten Behrens wrote: Hmm; the dx array as I understand it is just a simplified form of glyph widths; >>> >>> The DX stuff is pure madness (it is inspired by a Windows 3.1 API as I >>> have been told), you basically convert individual glyph advance widths >>> to absolute (from start of line IIRC) “character widths”; the x position >>> after the Nth character from the start of line, which is not so horrible >>> so far, except that when drawing the glyphs you take those absolute >>> character widths and try to convert them back to glyph >>> positions (that you already had but thrown away, remember) with all >>> sorts of bugs and rounding errors left and right (and hundreds of hacks >>> to work around the rounding errors). >> >> I have to agree with this assessment. The comment in the code for >> ApplyDXArray (I >> think was this from you Khaled? I added some info to it) is interesting: >> >> // To justify a text string, Writer calls OutputDevice::GetTextArray() >> // to get an array that maps input characters (not glyphs) to their absolute >> // position, GetTextArray() in turn calls SalLayout::FillDXArray() to get an >> // array of character widths that it converts to absolute positions. >> >> // Writer would then apply justification adjustments to that array of >> absolute >> // character positions and return to OutputDevice, which eventually calls >> // ApplyDXArray(), which needs to extract the individual adjustments for each >> // character to apply it to corresponding glyphs, and since that information >> is >> // already lost it tries to do some heuristics to guess it again. Those >> // heuristics often fail, and have always been a source of all sorts of weird >> // text layout bugs, and instead of fixing the broken design a hack after >> hack >> // have been applied on top of it, making it a complete mess that nobody >> // understands. > > That sounds like a frustrated me. > > Regards, > Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On Tue, Mar 08, 2016 at 10:18:47AM +1100, Chris Sherlock wrote: > On 8 Mar 2016, at 5:38 AM, Khaled Hosny wrote: > > > > On Mon, Mar 07, 2016 at 02:04:41PM +, Michael Meeks wrote: > >> Hi Thorsten, > >> > >>I missed your mail; please do maintain the CC if you want a prompt > >> reply =) > >> > >> On Fri, 2016-03-04 at 00:43 +0100, Thorsten Behrens wrote: > >> > >>Hmm; the dx array as I understand it is just a simplified form of glyph > >> widths; > > > > The DX stuff is pure madness (it is inspired by a Windows 3.1 API as I > > have been told), you basically convert individual glyph advance widths > > to absolute (from start of line IIRC) “character widths”; the x position > > after the Nth character from the start of line, which is not so horrible > > so far, except that when drawing the glyphs you take those absolute > > character widths and try to convert them back to glyph > > positions (that you already had but thrown away, remember) with all > > sorts of bugs and rounding errors left and right (and hundreds of hacks > > to work around the rounding errors). > > I have to agree with this assessment. The comment in the code for > ApplyDXArray (I > think was this from you Khaled? I added some info to it) is interesting: > > // To justify a text string, Writer calls OutputDevice::GetTextArray() > // to get an array that maps input characters (not glyphs) to their absolute > // position, GetTextArray() in turn calls SalLayout::FillDXArray() to get an > // array of character widths that it converts to absolute positions. > > // Writer would then apply justification adjustments to that array of absolute > // character positions and return to OutputDevice, which eventually calls > // ApplyDXArray(), which needs to extract the individual adjustments for each > // character to apply it to corresponding glyphs, and since that information > is > // already lost it tries to do some heuristics to guess it again. Those > // heuristics often fail, and have always been a source of all sorts of weird > // text layout bugs, and instead of fixing the broken design a hack after hack > // have been applied on top of it, making it a complete mess that nobody > // understands. That sounds like a frustrated me. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On 8 Mar 2016, at 8:39 AM, Norbert Thiebaud wrote: > > On Mon, Mar 7, 2016 at 10:22 AM, Thorsten Behrens > wrote: >> I'm afraid we're in for that regardless. Norbert, Khaled, Tor IIRC & a >> number of other hackers all came to the conclusion that the vcl font >> API / the way Writer is doing layout is in serious need for rework, > > My conclusion was that writer trying to mess with the layout directly > is an heresy > vcl should be doing the layout and writer and other may want to query > information about it (like the position of things for caret handling > purpose etc.. but should _never_ try to 'tweak' the positoing of > individual glyphs, even less via positioning individual character (to > the the n-n relation with glyphes) > > I do think that the first step is to push the layouting tweaks/hacks > out of writer and into vcl itself, > make dxarray read-only, > and _then_ we are free to implement/improve stuff in vcl as desired. > > Norbert > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/libreoffice Do you have any code pointers where writer modifies the layout? Chris ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On 8 Mar 2016, at 5:38 AM, Khaled Hosny wrote: > > On Mon, Mar 07, 2016 at 02:04:41PM +, Michael Meeks wrote: >> Hi Thorsten, >> >> I missed your mail; please do maintain the CC if you want a prompt >> reply =) >> >> On Fri, 2016-03-04 at 00:43 +0100, Thorsten Behrens wrote: >> >> Hmm; the dx array as I understand it is just a simplified form of glyph >> widths; > > The DX stuff is pure madness (it is inspired by a Windows 3.1 API as I > have been told), you basically convert individual glyph advance widths > to absolute (from start of line IIRC) “character widths”; the x position > after the Nth character from the start of line, which is not so horrible > so far, except that when drawing the glyphs you take those absolute > character widths and try to convert them back to glyph > positions (that you already had but thrown away, remember) with all > sorts of bugs and rounding errors left and right (and hundreds of hacks > to work around the rounding errors). I have to agree with this assessment. The comment in the code for ApplyDXArray (I think was this from you Khaled? I added some info to it) is interesting: // To justify a text string, Writer calls OutputDevice::GetTextArray() // to get an array that maps input characters (not glyphs) to their absolute // position, GetTextArray() in turn calls SalLayout::FillDXArray() to get an // array of character widths that it converts to absolute positions. // Writer would then apply justification adjustments to that array of absolute // character positions and return to OutputDevice, which eventually calls // ApplyDXArray(), which needs to extract the individual adjustments for each // character to apply it to corresponding glyphs, and since that information is // already lost it tries to do some heuristics to guess it again. Those // heuristics often fail, and have always been a source of all sorts of weird // text layout bugs, and instead of fixing the broken design a hack after hack // have been applied on top of it, making it a complete mess that nobody // understands. http://opengrok.libreoffice.org/xref/core/vcl/source/gdi/sallayout.cxx#901 Regardless of who wrote that comment, this is pretty insane. Chris ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On Mon, Mar 7, 2016 at 10:22 AM, Thorsten Behrens wrote: > I'm afraid we're in for that regardless. Norbert, Khaled, Tor IIRC & a > number of other hackers all came to the conclusion that the vcl font > API / the way Writer is doing layout is in serious need for rework, My conclusion was that writer trying to mess with the layout directly is an heresy vcl should be doing the layout and writer and other may want to query information about it (like the position of things for caret handling purpose etc.. but should _never_ try to 'tweak' the positoing of individual glyphs, even less via positioning individual character (to the the n-n relation with glyphes) I do think that the first step is to push the layouting tweaks/hacks out of writer and into vcl itself, make dxarray read-only, and _then_ we are free to implement/improve stuff in vcl as desired. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On Mon, Mar 7, 2016 at 8:04 AM, Michael Meeks wrote: > >> - as long as so much low-level layouting is still >> happening in Writer (dx arrays, kashida filling etc). > > Hmm; the dx array as I understand it is just a simplified form of > glyph > widths; Not quite. Dx array associate width to characters, not glyphs... a glyph can represent multiple characters and conversely a given character may be represented by multiple glyphs... so DX array is fundamentally broken when used in a non read-only fashion. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On Mon, Mar 07, 2016 at 02:04:41PM +, Michael Meeks wrote: > Hi Thorsten, > > I missed your mail; please do maintain the CC if you want a prompt > reply =) > > On Fri, 2016-03-04 at 00:43 +0100, Thorsten Behrens wrote: > > > Having looked at this heap; and worse - the two different heaps for > > > Windows text rendering, and also the big pile of strange cross-platform > > > issues with stacking diacritics, emojis etc. I'm pretty convinced that > > > we cannot do a good job of consistent text shaping and/or rendering > > > cross-platform while using the Windows font rendering infrastructure. > > > > Yeah, I suppose. But that alone won't fix the kind of issues you show > > in your ascii art > > Sure; the ascii art is the tip of one iceberg ie. not being able to get > accurate ABC widths and/or metrics for what we're rendering, and hence > having overlapping glyphs and broken selections in many corner-cases. > > > - as long as so much low-level layouting is still > > happening in Writer (dx arrays, kashida filling etc). > > Hmm; the dx array as I understand it is just a simplified form of glyph > widths; The DX stuff is pure madness (it is inspired by a Windows 3.1 API as I have been told), you basically convert individual glyph advance widths to absolute (from start of line IIRC) “character widths”; the x position after the Nth character from the start of line, which is not so horrible so far, except that when drawing the glyphs you take those absolute character widths and try to convert them back to glyph positions (that you already had but thrown away, remember) with all sorts of bugs and rounding errors left and right (and hundreds of hacks to work around the rounding errors). Most of time all you need is 1) where to draw the cursor after N character (VCL has an API specifically for cursor position that is not used for cursor position) 2) how much the spaces on the line need to expand for justification 3) where to insert kashidas and how many. All can be implemented with sane APIs that does not involve throwing positioning information then second guessing it. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On Fri, Mar 04, 2016 at 12:04:38PM +, Caolán McNamara wrote: > On Thu, 2016-03-03 at 13:44 +, Michael Meeks wrote: > > Hi guys, > > > Anyhow - what to do ? > > > > While we could switch to DirectWrite on windows, which may > > solve some > > of our problems; this will be in itself disruptive. > > > > So - I believe that we should switch to using harfbuzz and > > freetype consistently everywhere. > > So, like chromium and firefox etc do, I'm very much in favor of using > our harfbuzz text shaper on all platforms to unify that complexity and > have equal layout problems on different platforms :-). > > If you look at the vcl/unx/generic/glyphs/gcach_layout.cxx getFontFuncs > thing (and the firefox equivalents) then harfbuzz has mechanisms to > allow us to integrate with CGFontRefs on MacOSX, FT_Face under Linux > and presumably (?) hook into our existing Windows stuff to swap out the > two windows shaping engines and keep (one of) the existing render paths > ? HarfBuzz has callbacks to get some of the stuff it wants from fonts, char to glyph mapping, etc. This can be hocked into FreeType, Core Text, DirectWrite or even GDI APIs, so you can keep loading/rendering fonts with platform “native” API and use HarfBuzz for shaping and positioning. Recent versions of HarfBuzz even has its internal font functions and you just give it a memory blob representing the font file and it will read the font tables on its own (Chrome has recently switched to using that, for example) this means even more consistency since, for example, FreeType can return different metrics in different versions. > So layout wise I'm comfortable with harfbuzz everywhere. Window text > rendering is as clear as mud to me though. Right now under Linux (and > similar platforms) at the moment we are using cairo to render glyphs > (from freetype faces) rather that using freetype to do that directly. > And under Linux we render visually differently, albeit with the same > positioning, depending on what features of the underlying freetype are > enabled or disabled and all mediated by what desktop-wide font options > are set. My experiences there suggests that if your text doesn't look > like everyone else's on that platform there's constant moaning and > complaining. > > On Windows, peer apps like firefox and chromium etc seem to follow the > pattern of eventually rendering their harfbuzz layouted text with the > DirectWrite apis, whether directly, or through skia or through a forked > cairo, that *seems* be where things end up. So that seems to be a > fairly well trodden route. Not using the “native” font rendering APIs is indeed more controversial as it means you don’t respect system wide font rendering/hinting etc. options which will be very visible especially on Windows since FreeType’s support for ClearType hinting is rather incomplete. Shaping difference on the other hand is more subtle, and HarfBuzz tries to maintain computability with MS implementation (this does not help with Mac OS X implementation, but usually differences there are considered bugs in Apple implementation). Another problem with using FreeType is it can be tricky to integrate it with platform font searching APIs, there is no direct way, for example, to create an FT_Face from a CTFont as FreeType wants either a filename and face index (for font collections) or the full font memory blob and CTFont has no API that gives this. Even if it has, you will end up loading the font twice in memory, though this might not be such a big issue. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On 7 March 2016 at 18:22, Thorsten Behrens wrote: > You're getting different rounding even depending on the flags your OS > (or driver that happens to be in your process) sets. Seriously - I'm > too lazy to dig out references, but consider floating point math to be > inherently non-similar from one box to the next, *unless* you're > extremely careful across the entire calculation chain (which is the > case in Calc). > While this is an issue for actual math on potentially very large or very small numbers (which is, I assume, why calc is careful with it), and an issue for games with large 3D worlds, it can hardly be an issue for the magnitudes of numbers we deal with in the font rendering paths. > C.f. chart2. > Even chart2's world-geometry is relatively small in the grander scale of things. And issues there have far less impact than the glaring font rendering issues elsewhere. > I'm afraid we're in for that regardless. Norbert, Khaled, Tor IIRC & a > number of other hackers all came to the conclusion that the vcl font > API / the way Writer is doing layout is in serious need for rework, > before any amount of font layouting/rendering happiness can be > attained. Surely that orthogonal is to the font-rendering down in the VCL layer. We can fix the one without making the other any worse. I would assume that attempting to fix both at the same time would be a boiling-the-ocean type problem, much better to work on them independently. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
Michael Meeks wrote: > I missed your mail; please do maintain the CC if you want a prompt > reply =) > Setting Reply-To would help me to remember that next time. ;) > Hmm; the dx array as I understand it is just a simplified form of > glyph widths; we could use rectangles for those instead of > non-linear selection handling to be more cute ? ultimately an > intimate view of text seems quite inevitable to me in writer - but > I'm no writer expert. > Nah. The problem is that boxes-for-glyphs in a linear array are the wrong abstraction (it gets quite funky for ltr-rtl and other complex text layout mixes), and having them integer-only a) gives you AA-bleed into the next glyph's box, and/or b) ugly whitespace jumpiness for smaller font sizes (check a line of WaWaWaWaW with an 8pt font...) The way it's implemented (Writer does the layout, passes DX array down) also *really* kills the nicer font features like alternate glyphs. > > > While we could switch to DirectWrite on windows, which may solve some > > > of our problems; this will be in itself disruptive. > > > > Incidentally - why that? > > Switching to DirectWrite ? its a better API cf. the link I gave, it is > part of the Universal Windows Platform (UWP) - but note that using > freetype/cairo for rendering is also UWP compatible ;-) > Nah - I meant, why is that in itself disruptive? ;) > > > So - I believe that we should switch to using harfbuzz and freetype > > > consistently everywhere. This would have the huge benefit of precise > > > cross-platform font rendering and metric fidelity, give us a font and > > > shaping stack that is fully introspectable, drop some legacy Windows API > > > usage, and allow all development work and fixing on all platforms to > > > share the same underlying code. > > > > > I think that promise cannot be kept. > > Curious - which promise ? the font rendering and metric fidelity across > platforms ? > The 'develop once, run everywhere' promise. ;) > > Let's evaluate the merit of switching to some truly great floss libraries > > based on other aspects - you're not even getting consistent floating point > > math between different CPUs, let alone different operating systems... > > I would hope that the OS' impact on floating point math is rather > small; I'm also extremely curious about the inconsistent floating point > math problems people posit here. > You're getting different rounding even depending on the flags your OS (or driver that happens to be in your process) sets. Seriously - I'm too lazy to dig out references, but consider floating point math to be inherently non-similar from one box to the next, *unless* you're extremely careful across the entire calculation chain (which is the case in Calc). > IEE754 is pretty helpful - and when it comes to rendering rather > small glyphs - and accumulating their metrics via a few adds & > subtracts across any feasible page size - it seems incredible to me > that this would cause issues. > C.f. chart2. > For sure depending on how the compiler handles the FPU registers we > could have only 23 bits of fraction instead of the 32 we'd expect to > retain if left on the GPU - but really ... 2^23 is reasonably large > for rendering a 40 pixel square glyph surely ? =) > Unless you convert from register to mem and back for every calculation step, you've no real portable control over intermediate values. And the precision argument is moot, e.g. when facing catastrophic cancellation. > Now of course for complex text, it's not just rendering simple, US > ASCII strings - it's a font fallback / shaping nightmare =) but if the > glyph rendering can work cross-platform, I'm optimistic the shaping can > too. This underlies my confidence that we can do reliable layout unit > test across platforms - assuming we can nail down shaping & font code. > Ah well. That's really a re-hash of an old discussion - perhaps something then for a non-email exchange of ideas. ;) Anyway - as I wrote to Caolan, if there's a Uniscribe/DirectWrite code path in your proposed solution, my concerns are moot (the above issues will remain, but it's no worse than today). > > Since I guess for most complaints about layouting problems I hear about, > > it's the different between MSO and LibreOffice, rather than between > > LibreOffice > > on different platforms. ;) > > Sure; but unfortunately, the stack is such a mess now that fixing this > (really non-intuitive) code and/or adding features multiple times and > testing across platforms is really a very long way from ideal. > I'm afraid we're in for that regardless. Norbert, Khaled, Tor IIRC & a number of other hackers all came to the conclusion that the vcl font API / the way Writer is doing layout is in serious need for rework, before any amount of font layouting/rendering happiness can be attained. Cheers, -- Thorsten signature.asc Description: Digital signature
Re: Windows / font / text futures ...
Hi Michael, Am 07.03.2016 um 15:29 schrieb Michael Meeks: Hi Armin, Interesting mail; please do CC me on replies =) On Fri, 2016-03-04 at 11:25 +0100, Armin Le Grand wrote: On the danger no-one wants to hear it :-) - Primitives. If all text rendering would use them, all text rendering could be handled in system-specific renderer implementations. If we could cache de-compositions of primitives instead of constantly re-generating them, I think it'd be great to have a list of glyphs and positions for a given string - continually re-shaping the same text as we measure, render, etc. as we currently do seems (to me) particularly pointless and inefficient - particularly when you have some really complex text shaper. AFAIK Text primitives are currently not decomposed at all, they are all directly handled in the VCL-Renderer. If they would be decomposed, they would be fully buffered, that is the default for primitives. An external renderer would also handle them directly, so also no need to decompose. If needed, results can be buffered at the primitive itself. All possibilities are given. Similar for layout, I have already 'isolated' text layout stuff needed for primitive text handling in a class called 'TextLayouterDevice' that has a small number of interface method and uses OutputDevice in the background. That class can be implemented system-specific or based on an external tooling dood on all systems. Sure - abstraction is nice; but not having to abstract - by sharing more of the rendering infrastructure is even more ideal IMHO =) Abstraction is of course a question of weighting. This abstraction is for 'hiding' FontLayout from OutputDevice - a separation that is missing from the beginning. It is just hiding stuff, not even virtual function calls involved. Office is mostly a text tool, so from my POV there is no way around using the *best* font rendering on every system. Having (well-optimized) ClearType on a system and not using it in an office application will not be accepted, esp. not when telling 'but that way it is better on a system you do not use'. Hmm; I'm not so convinced that with today's higher-dpi screens and better rendering / hinting algorithms there is so much in it. ClearType is rather (oddly) situation specific too - mostly good for mostly black text on a mostly white background ;-) Amusingly - I wanted to demo that so I fired up Office 2016 on Windows 7: https://people.gnome.org/~michael/office2016.png Not knowingly configured Office at all since I installed it. Notice that this is indeed a ClearType setup - cf. the Calibri preview in the widget. If I was a betting man, this would be down to the horrible complaints that people no doubt make - since copy/pasting eg. formulae between word & excel these days results in a bitmap - which used to be complete with false colour but ... no time for a more systematic test. Luckily indeed this gets less important with growing resolution. Still - I am convinced that it is expected that we use the best FontRendering on each system. ATB, Michael. -- -- ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
Hi Armin, Interesting mail; please do CC me on replies =) On Fri, 2016-03-04 at 11:25 +0100, Armin Le Grand wrote: > On the danger no-one wants to hear it :-) - Primitives. If all text > rendering would use them, all text rendering could be handled in > system-specific renderer implementations. If we could cache de-compositions of primitives instead of constantly re-generating them, I think it'd be great to have a list of glyphs and positions for a given string - continually re-shaping the same text as we measure, render, etc. as we currently do seems (to me) particularly pointless and inefficient - particularly when you have some really complex text shaper. > Similar for layout, I have already 'isolated' text layout stuff needed > for primitive text handling in a class called 'TextLayouterDevice' > that has a small number of interface method and uses OutputDevice in > the background. That class can be implemented system-specific or based > on an external tooling dood on all systems. Sure - abstraction is nice; but not having to abstract - by sharing more of the rendering infrastructure is even more ideal IMHO =) > Office is mostly a text tool, so from my POV there is no way around > using the *best* font rendering on every system. Having > (well-optimized) ClearType on a system and not using it in an office > application will not be accepted, esp. not when telling 'but that way > it is better on a system you do not use'. Hmm; I'm not so convinced that with today's higher-dpi screens and better rendering / hinting algorithms there is so much in it. ClearType is rather (oddly) situation specific too - mostly good for mostly black text on a mostly white background ;-) Amusingly - I wanted to demo that so I fired up Office 2016 on Windows 7: https://people.gnome.org/~michael/office2016.png Not knowingly configured Office at all since I installed it. Notice that this is indeed a ClearType setup - cf. the Calibri preview in the widget. If I was a betting man, this would be down to the horrible complaints that people no doubt make - since copy/pasting eg. formulae between word & excel these days results in a bitmap - which used to be complete with false colour but ... no time for a more systematic test. ATB, Michael. -- michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
Hi Thorsten, I missed your mail; please do maintain the CC if you want a prompt reply =) On Fri, 2016-03-04 at 00:43 +0100, Thorsten Behrens wrote: > > Having looked at this heap; and worse - the two different heaps for > > Windows text rendering, and also the big pile of strange cross-platform > > issues with stacking diacritics, emojis etc. I'm pretty convinced that > > we cannot do a good job of consistent text shaping and/or rendering > > cross-platform while using the Windows font rendering infrastructure. > > Yeah, I suppose. But that alone won't fix the kind of issues you show > in your ascii art Sure; the ascii art is the tip of one iceberg ie. not being able to get accurate ABC widths and/or metrics for what we're rendering, and hence having overlapping glyphs and broken selections in many corner-cases. > - as long as so much low-level layouting is still > happening in Writer (dx arrays, kashida filling etc). Hmm; the dx array as I understand it is just a simplified form of glyph widths; we could use rectangles for those instead of non-linear selection handling to be more cute ? ultimately an intimate view of text seems quite inevitable to me in writer - but I'm no writer expert. > > While we could switch to DirectWrite on windows, which may solve some > > of our problems; this will be in itself disruptive. > > Incidentally - why that? Switching to DirectWrite ? its a better API cf. the link I gave, it is part of the Universal Windows Platform (UWP) - but note that using freetype/cairo for rendering is also UWP compatible ;-) > > So - I believe that we should switch to using harfbuzz and freetype > > consistently everywhere. This would have the huge benefit of precise > > cross-platform font rendering and metric fidelity, give us a font and > > shaping stack that is fully introspectable, drop some legacy Windows API > > usage, and allow all development work and fixing on all platforms to > > share the same underlying code. > > > I think that promise cannot be kept. Curious - which promise ? the font rendering and metric fidelity across platforms ? > Let's evaluate the merit of switching to some truly great floss libraries > based on other aspects - you're not even getting consistent floating point > math between different CPUs, let alone different operating systems... I would hope that the OS' impact on floating point math is rather small; I'm also extremely curious about the inconsistent floating point math problems people posit here. IEE754 is pretty helpful - and when it comes to rendering rather small glyphs - and accumulating their metrics via a few adds & subtracts across any feasible page size - it seems incredible to me that this would cause issues. For sure depending on how the compiler handles the FPU registers we could have only 23 bits of fraction instead of the 32 we'd expect to retain if left on the GPU - but really ... 2^23 is reasonably large for rendering a 40 pixel square glyph surely ? =) Then again - perhaps I'm completely mistaken. Other people seem to be able to do this: one example might be the Acid 3 canvas rendering test: http://acid3.acidtests.org/ cf. https://en.wikipedia.org/wiki/Acid3 - which (I hope) runs on your browser - and includes both text (with shadow), and a pixel-by-pixel compatibility requirement; at least it looks like text. Now of course for complex text, it's not just rendering simple, US ASCII strings - it's a font fallback / shaping nightmare =) but if the glyph rendering can work cross-platform, I'm optimistic the shaping can too. This underlies my confidence that we can do reliable layout unit test across platforms - assuming we can nail down shaping & font code. > > There will of course also be some corner-cases where we may simply not > > be able to replicate the tangled old layout behaviour - which is > > (anyway) inconsistent across platforms - but - I think this is a one-off > > risk that is well worth taking to get us to a fully consistent, Free > > Software rendering stack. It is interesting that Microsoft also used > > freetype > > for their Office / Mac rendering in the recent past =) > > Oh - got some reference for that ? Sure; of course quite possibly I was gotcha'd by some photo-shopping weenie =) http://tech.slashdot.org/story/10/08/30/1419227/freetype-lands-in-microsoft-office > Since I guess for most complaints about layouting problems I hear about, > it's the different between MSO and LibreOffice, rather than between > LibreOffice > on different platforms. ;) Sure; but unfortunately, the stack is such a mess now that fixing this (really non-intuitive) code and/or adding features multiple times and testing across platforms is really a very long way from ideal. ATB, Michael. -- michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot ___
Re: Windows / font / text futures ...
Caolan McNamara wrote: > On Windows, peer apps like firefox and chromium etc seem to follow > the pattern of eventually rendering their harfbuzz layouted text > with the DirectWrite apis, whether directly, or through skia or > through a forked cairo, that *seems* be where things end up. So that > seems to be a fairly well trodden route. > Ah, that would address most of my concerns. Shame wrt. the forked cairo though... Cheers, -- Thorsten signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
On Thu, 2016-03-03 at 13:44 +, Michael Meeks wrote: > Hi guys, > Anyhow - what to do ? > > While we could switch to DirectWrite on windows, which may > solve some > of our problems; this will be in itself disruptive. > > So - I believe that we should switch to using harfbuzz and > freetype consistently everywhere. So, like chromium and firefox etc do, I'm very much in favor of using our harfbuzz text shaper on all platforms to unify that complexity and have equal layout problems on different platforms :-). If you look at the vcl/unx/generic/glyphs/gcach_layout.cxx getFontFuncs thing (and the firefox equivalents) then harfbuzz has mechanisms to allow us to integrate with CGFontRefs on MacOSX, FT_Face under Linux and presumably (?) hook into our existing Windows stuff to swap out the two windows shaping engines and keep (one of) the existing render paths ? So layout wise I'm comfortable with harfbuzz everywhere. Window text rendering is as clear as mud to me though. Right now under Linux (and similar platforms) at the moment we are using cairo to render glyphs (from freetype faces) rather that using freetype to do that directly. And under Linux we render visually differently, albeit with the same positioning, depending on what features of the underlying freetype are enabled or disabled and all mediated by what desktop-wide font options are set. My experiences there suggests that if your text doesn't look like everyone else's on that platform there's constant moaning and complaining. On Windows, peer apps like firefox and chromium etc seem to follow the pattern of eventually rendering their harfbuzz layouted text with the DirectWrite apis, whether directly, or through skia or through a forked cairo, that *seems* be where things end up. So that seems to be a fairly well trodden route. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
Hi Thorsten and Michael, Am 04.03.2016 um 00:43 schrieb Thorsten Behrens: Hi Michael, you write: Having looked at this heap; and worse - the two different heaps for Windows text rendering, and also the big pile of strange cross-platform issues with stacking diacritics, emojis etc. I'm pretty convinced that we cannot do a good job of consistent text shaping and/or rendering cross-platform while using the Windows font rendering infrastructure. Yeah, I suppose. But that alone won't fix the kind of issues you show in your ascii art - as long as so much low-level layouting is still happening in Writer (dx arrays, kashida filling etc). On the danger no-one wants to hear it :-) - Primitives. If all text rendering would use them, all text rendering could be handled in system-specific renderer implementations. Similar for layout, I have already 'isolated' text layout stuff needed for primitive text handling in a class called 'TextLayouterDevice' that has a small number of interface method and uses OutputDevice in the background. That class can be implemented system-specific or based on an external tooling dood on all systems. Rendering can also be system-specific or use such unified external tooling. Think about something mixed like: No longer layout each char of a word, but the whole word. On rendering, check how long would it be painted, adapt with width zooming slightly to get the same width. When layout of single word width is done system-independent that might give good results. This would require to go forward with converting all EditView visualizations to use primitives, though. Just my 2ct :-) While we could switch to DirectWrite on windows, which may solve some of our problems; this will be in itself disruptive. Incidentally - why that? So - I believe that we should switch to using harfbuzz and freetype consistently everywhere. This would have the huge benefit of precise cross-platform font rendering and metric fidelity, give us a font and shaping stack that is fully introspectable, drop some legacy Windows API usage, and allow all development work and fixing on all platforms to share the same underlying code. I think that promise cannot be kept. Let's evaluate the merit of switching to some truly great floss libraries based on other aspects - you're not even getting consistent floating point math between different CPUs, let alone different operating systems... Office is mostly a text tool, so from my POV there is no way around using the *best* font rendering on every system. Having (well-optimized) ClearType on a system and not using it in an office application will not be accepted, esp. not when telling 'but that way it is better on a system you do not use'. There will of course also be some corner-cases where we may simply not be able to replicate the tangled old layout behaviour - which is (anyway) inconsistent across platforms - but - I think this is a one-off risk that is well worth taking to get us to a fully consistent, Free Software rendering stack. It is interesting that Microsoft also used freetype for their Office / Mac rendering in the recent past =) Oh - got some reference for that? Since I guess for most complaints about layouting problems I hear about, it's the different between MSO and LibreOffice, rather than between LibreOffice on different platforms. ;) Cheers, -- Thorsten ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice -- ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Windows / font / text futures ...
Hi Michael, you write: > Having looked at this heap; and worse - the two different heaps for > Windows text rendering, and also the big pile of strange cross-platform > issues with stacking diacritics, emojis etc. I'm pretty convinced that > we cannot do a good job of consistent text shaping and/or rendering > cross-platform while using the Windows font rendering infrastructure. > Yeah, I suppose. But that alone won't fix the kind of issues you show in your ascii art - as long as so much low-level layouting is still happening in Writer (dx arrays, kashida filling etc). > While we could switch to DirectWrite on windows, which may solve some > of our problems; this will be in itself disruptive. > Incidentally - why that? > So - I believe that we should switch to using harfbuzz and freetype > consistently everywhere. This would have the huge benefit of precise > cross-platform font rendering and metric fidelity, give us a font and > shaping stack that is fully introspectable, drop some legacy Windows API > usage, and allow all development work and fixing on all platforms to > share the same underlying code. > I think that promise cannot be kept. Let's evaluate the merit of switching to some truly great floss libraries based on other aspects - you're not even getting consistent floating point math between different CPUs, let alone different operating systems... > There will of course also be some corner-cases where we may simply not > be able to replicate the tangled old layout behaviour - which is > (anyway) inconsistent across platforms - but - I think this is a one-off > risk that is well worth taking to get us to a fully consistent, Free > Software rendering stack. It is interesting that Microsoft also used freetype > for their Office / Mac rendering in the recent past =) > Oh - got some reference for that? Since I guess for most complaints about layouting problems I hear about, it's the different between MSO and LibreOffice, rather than between LibreOffice on different platforms. ;) Cheers, -- Thorsten signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Windows / font / text futures ...
Hi guys,
I've had the (mixed) pleasure of digging through the windows font
rendering in recent days; and I must say - I'm not thoroughly thrilled
with it =)
Let me highlight a few of the problems. First we are using GDI for text
rendering, and this is ~obsolete. Several interesting problems are
pointed out here:
http://blogs.msdn.com/b/text/archive/2009/04/15/introducing-the-directwrite-font-system.aspx
Let me excerpt the rather charitable summary of what I've been falling
over:
"For applications that need to work with fonts at a lower level,
GDI does have some functions that can really be thought of as
physical font APIs. Examples are GetFontData, GetGlyphIndices,
and even ExtTextOut when used with the ETO_GLYPH_INDEX flag.
Yet these “physical” font functions still use an HFONT to
specify the font. This means font mapping still occurs under
the hood, though since no text is specified there is no font
fallback and the same HFONT always maps to the same physical
font internally. While this model works, the lack of a true
physical font object in GDI can make it harder for application
developers that use these low-level functions to be sure of
what is going on."
Something of an under-statement there =) As far as I can see the
SimpleWinLayout - which we use sometimes (in place of the UniScribe layout)
and which has a number of fun comments in it like:
// TODO: support surrogates in rewritten strings
Essentially re-uses the non-obvious, not-really-physical-font
logic with built-in windows font fallback. In contrast the UniScribe
layout engine does not.
The particular issue I'm looking at is that it appears really hard to
get genuine ABC widths (ie. underhang, black-width, and overhang
information) for those fall-back glyphs that are actually not in the
physical font - but that Windows (un)helpfully includes from elsewhere.
Asking for metrics via 'GetCharABCWidths' yields the 'default character's
metrics:
"The ABC widths of the default character are used for characters
outside the range of the currently selected font."
Where by font, they mean physical font ignoring fallbacks it seems.
After lots of nice drawings - thanks to Tor for his nice font rendering
foo, of this kind; notice the '$' character appears from another font,
with inaccurate ABC width - hence the overlap.
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:540: DX:offset : 17:1
10:2 11:1 9:2 11:0 0:1
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:266: this=0CC6A0E8 32
old: {[43..48],[182..187],[286..291],[9832..9837],[9858..9863],[55356..55361]}
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:357: ABC widths: 0:1:14
3:3:3 1:8:1 0:16:0 1:8:2 0:22:2
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:431: OpenSymbol:
Escapement=0 Orientation=0 Ascent=23 InternalLeading=0 Size=(87,29) totWidth=82
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:533: this=0CC6A0E8 now:
{[32..37],[43..48],[182..187],[286..291],[9832..9837],[9858..9863],[55356..55361]}
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:176: Bitmap 7705322A:
82x33:
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:205: | |
|||
| ||||
| ||||
| ||||
| || 7X29 92X7 ||
| 719 | 3X0880X3 | 3X5 9108 ||3XX19
925
| 80X3 | 3X0880X3 | 92X7 8029 | 818 | 92199219
53
| 7XX29 | 3X0880X3 | 9108 5X3| 818 | 7X5 7X3
829
| 7XX29 | 3X0880X3 | 8029 3X5|807 | 3X7 8019 927
| 7XX29 | 3X1991X5 | 5X3 9208| 5XXX3| 91X7 8008 53
| 80X3 | 7X2992X7 | 92XX5 | 80X58187XX|791X7 9108829
| 80X3 | 803 508 | 92XX5 | 5X3 818 3X|391X7 8008 927
| 91X5 || 9108 5X3 | 3X5 818 | 3X7 8019 53
| 92X7 || 8029 3X7 | 3X3 818 | 7X5 7X3 829
| 3X7 || 5X3 9208 | 7XX5818 | 92199219 927
| 308 || 3X5 8019 | 529 |3XX19 53
| 519 ||9208 7X29 |92X5| 829
92XX19
| 729 || 3XX3 | 8160XX|5 927
92199208
| 84 || 3XX3 | 818 3X|2953
5X5 7X3
| 95 ||5X3 9208 | 818 80|19 829
92X7 8019
| ||3X5 8019 | 91X7 818 80|19 927
91X7 9108
| |
