[Libreoffice-commits] core.git: vcl/source

[Chris Sherlock]

 vcl/source/gdi/sallayout.cxx |   23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

New commits:
commit 7201fa0dddd7dd0352f69fd2b2b64efcb361ccad
Author: Chris Sherlock <chris.sherlock79 at gmail.com>
Date:   Mon Jan 12 10:00:31 2015 +1100

    vcl: update comments about GenericSalLayout::ApplyDXArray
    
    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

diff --git a/vcl/source/gdi/sallayout.cxx b/vcl/source/gdi/sallayout.cxx
index 4d9ee51..ad34efd 100644
--- a/vcl/source/gdi/sallayout.cxx
+++ b/vcl/source/gdi/sallayout.cxx
@@ -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 )
 {