[Libreoffice-bugs] [Bug 104597] Text runs of RTL scripts (e.g. Arabic, Hebrew, Persian) from imported PDF are reversed, PDFIProcessor::mirrorString not behaving

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=104597

--- Comment #49 from Armin Le Grand <Armin.Le.Grand at me.com> ---
It's a 3x3 homogen transformation matrix as known from linear algebra and used
in CG systems. Usually only 3x2 is used since the last line may host
perspective change stuff, but usually not used in 2D CG.
You may look in any book or google for it. It is a combination of Scale, Shear,
Rotate and Translate. It can be decomposed to these (use decompose() at the
matrix) to get the single parts.

To make it short,
    rCurGC: 1200 0 46240 0 1200 5674.08
means: scale(1200, 1200), then translate(46240, 5674.08), no rotation/shear
used here (that would be multipied into the values, so the two zeros indicate
this). This describes what to do when you imagine the character being at (0,0)
and of size(1,1) (unit coordinates) to get it to where it is need to be shown.
In case of no rotate/shear, it's like a rectangle (0,0,46240, 5674.08).

That these rectangles increase in X just describes that the next defined
character is right of the one before - you may substract the X-Values to get
the distances. So - that values are correct from the definition(s).

Objects are without shear/rotate, so the note line
    // line and space optimization; works only in strictly horizontal mode
is okay - that may be adapted to also be able to concatenate with
back-transformations, just a hint, that limitation is theoretically not needed,
but would make things more complicated...

When you substract the X-Values to get the character widths you will note these
are not 1200 -> due to scale for fonts has special meaning. Y-Scale indeed is
the char height, but X-Scale is defined 'relative' to Y-Scale, so X==Y here
means no unregular font scaling (some systems also use a zero for X-Scale in
that case).

Thus indeed the comparison
    rCurGC.Transformation == rNextGC.Transformation
is nonsense - to be true, the current character would have to be at the same
position and of the same size (and rotate/shear if used) as the next one which
would mean they are defined to cover each other.

What would need to be compared is

    X(curr) + currCharWitdh <-similar-> to X(next)

with the problem where to get currCharWitdh from (and to add some
'unsharpness', see same file line 586, the multiply with 0.75).

This can be done when the Font is already available, by setting that font at an
temp OutDev, setting the FontWidth(1200) and getting the TextLength of a String
with that single character.

Maybe I overlook something (nobody is perfect), but I would have to debug & see
if that works with latin text - and why. From looking at the current code I am
not sure this ever did something...?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210715/117be6d4/attachment.htm>