mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vcl: update comments about GenericSalLayout::ApplyDXArray

Browse Source 
Basically, the issue noted here (justification adjustment issues in CTL) is
a legacy problem caused by emulating the EmrText structure, which is an
Enhanced Metafile (EMF) structure (or "object"). The EmrText structure holds
an array of inter-character spacing widths for text. It is used in the EMF
records EMR_EXTTEXTOUTA and EMR_EXTTEXTOUTW, which is flawed in that it
doesn't consider issues around CTL scripts and only cares about character
interspacing - i.e. it maps to each printable character, and doesn't take into
consideration other sorts of glyphs.

Change-Id: Ib7ae994758a835e9d8cb5f479a0b91d3d5809b8c
This commit is contained in:
Chris Sherlock
2015-01-12 10:00:31 +11:00
parent 5ae245a889
commit 7201fa0ddd
1 changed files with 19 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
vcl/source/gdi/sallayout.cxx
View File

@@ -957,7 +957,22 @@ 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()
// telling).
// Note: That would be the EMRTEXT structure, which is part of the EMF spec (see
// [MS-EMF] section 2.2.5. Basically the field in question is OutputDx, which is:
//
// "An array of 32-bit unsigned integers that specify the output spacing
// between the origins of adjacent character cells in logical units."
//
// This obviously makes sense for ASCII text (the EMR_EXTTEXTOUTA record), but it
// doesn't make sense for Unicode text (the EMR_EXTTEXTOUTW record) because it is
// mapping character codes to output spacing, which obviously can cause problems
// with CTL. MANY of our concepts are based around Microsoft data structures, this
// is obviously one of them and we probably need a rethink about how we go about
// this.
// 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.
@@ -972,9 +987,9 @@ void GenericSalLayout::AdjustLayout( ImplLayoutArgs& rArgs )
// 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?
// As you can see by now, this is utterly stupid, why doesn't Writer just send
// us the advance width transformations it wants to apply to each character directly
// instead of this whole mess?
void GenericSalLayout::ApplyDXArray( ImplLayoutArgs& rArgs )
{