Bugous bug fix

[Zolnai Tamás]

OK. I found it. The commit is right, with this changes all code which use
borderline primitive use MAP_PIXEL pattern and with the scale parameter the
pixel snippets is converted to the right length ones. The actual problem is
with the MAP_PIXEL pattern. The other two patterns (MAP_TWIP and
MAP_100TH_MM) are screen-independent so they can be constant, but pixel is
not screen-independent so the MAP_PIXEL pattern must be changing by text
zoom, otherwise the whole borderline length will changing but the snippets'
length not (which is happening by now).
The solution might be to use one of screen-independent pattern as it was
used originally and which works for Writer. The problem is that Calc
convert borderline parameters (start and end point, width) to pixel before
make a border line primitive. Plus it specifies an identity matrix as view
transformation matrix from which we can't get the information to transform
the used unit to pixel (to match the primitive's unit and the snippets'
unit). So I can't see a good solution.

Best regards,
Tamás


2013/9/19 Zolnai Tamás <zolnaitamas2000 at gmail.com>

> That's right.
>> When we call "ApplyLineDashing without scale", the snipet size is
>> completely different in Calc and Writer.
>> "ApplyLineDashing with scale" is intended to prevent this.
>> In LibreOffice 3.3, the size of the snipet was roughly the same in the
>> appearance on the screen in both programs.
>>
>
> Hmm, I see. That is solved, by now both programs have the same behavior,
> just a bit bugous. Ok, I will look into the code a bit more and try to find
> out what's going on here.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130920/968c9d8d/attachment.html>