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

1 files changed, 19 insertions, 4 deletions

diff --git a/vcl/source/gdi/sallayout.cxx b/vcl/source/gdi/sallayout.cxx
index 4d9ee516c259..ad34efd06bf2 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 )
 {