diff options
| author | Khaled Hosny <khaledhosny@eglug.org> | 2013-10-30 09:34:38 +0200 |
|---|---|---|
| committer | Khaled Hosny <khaledhosny@eglug.org> | 2013-10-30 09:39:42 +0200 |
| commit | 71077148d442b3bbfeefd9a572942946c6a95823 (patch) | |
| tree | 92d4c1db4421a43063d849772b847d5d02a3e27d /vcl/source | |
| parent | 8886336141dcbf21961d0c86a82f6224d7ac7a31 (diff) | |
fdo#70968: Incorrect rendering of Devanagari short 'i' vowel
It seems that some Indic fonts assign 'mark' glyph class to combining
spacing marks (spacing not non spacing) so my reliance on the glyph
class to set the IS_DIACRITIC flags broke those fonts. This is a bandaid
to get around the issue, plus some long rant! (at this rate, I'll be
writing "The VCL haters handbook" pretty soon).
Change-Id: I3ff892acf746d50182573f94e7e8c3c6f9464ae0
Diffstat (limited to 'vcl/source')
| -rw-r--r-- | vcl/source/gdi/sallayout.cxx | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/vcl/source/gdi/sallayout.cxx b/vcl/source/gdi/sallayout.cxx index f395936b34d7..450ec2325731 100644 --- a/vcl/source/gdi/sallayout.cxx +++ b/vcl/source/gdi/sallayout.cxx @@ -1018,6 +1018,27 @@ void GenericSalLayout::AdjustLayout( ImplLayoutArgs& rArgs ) // ----------------------------------------------------------------------- +// This DXArray thing is one of the stupidest ideas I have ever seen (I've been +// told that it probably a one-to-one mapping of some Windows 3.1 API, which is +// telling). 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. +// +// As you can see by now, this is utterly stupid, why Writer does not just send +// us directly the advance width transformations it wants to apply to each +// character instead of this whole mess? + void GenericSalLayout::ApplyDXArray( ImplLayoutArgs& rArgs ) { if( m_GlyphItems.empty()) |