Re: Bugous bug fix
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 > 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. > > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bugous bug fix
> > 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. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bugous bug fix
Hi Zolnai, I'm sorry for the late reply. >There is a small part of the patch, which make to draw hairline primitive, >when the line is solid (before only the width was checked). Maybe this part >fixed the original bug, because as I see the hairline primitive means a solid line. Please refer to the fdo#37129. https://bugs.freedesktop.org/show_bug.cgi?id=37129 >I made some screen shot, which shows dashed border changing with zoom level. >It's important that the same code is used by Writer so it has the same issue. (snip) >2. Call ApplyLineDashing without scale (but the used unit is MAP_PIXEL) >Calc will work similar. >Writer will loose the zooming issue but the snippets will be too small, >because of the pixel pattern of ApplyLineDashing. 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. Best regards, Tomofumi Yagi. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bugous bug fix
On Thu, 2013-09-12 at 10:49 +0200, Zolnai Tamás wrote: > Hi Tomofumi and Cedric, > I found that the next commit is bugous: > http://cgit.freedesktop.org/libreoffice/core/commit/?id=8c2902ecbf135fae070ea032fa10a59bb76ec1b0 > > I have problem mostly with using the ApplyLineDashing method with > scale parameter (borderlineprimitive2d.cxx). > I know two reasons why this is wrong: > ... > There is a small part of the patch, which make to draw hairline > primitive, when the line is solid (before only the width was checked). > Maybe this part fixed the original bug, because as I see the hairline > primitive means a solid line. Can you submit a patch that reverts the parts that you believe are problematic and keeps the part you think might be useful for the original problem ? How do we visually see the problems you describe ? If I put some dashed borders on some cells in calc and zoom in and out it doesn't seem to look particularly wrong for me. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bugous bug fix
Hi Tomofumi and Cedric, I found that the next commit is bugous: http://cgit.freedesktop.org/libreoffice/core/commit/?id=8c2902ecbf135fae070ea032fa10a59bb76ec1b0 I have problem mostly with using the ApplyLineDashing method with scale parameter (borderlineprimitive2d.cxx). I know two reasons why this is wrong: - The value of aScale.getLength() increase when text zoom is decrease, while it should decrease too. So when the text (or content of the border) is the smallest the dashed border's snippets are the biggest, which is a bit weird. - The whole borderline primitive is transformed before drawing, so no need to change the size of snippets separately, because this happens during the mentioned transformation. Additionally this change causes the borderline changing all the time while zooming and not just the size, but the snippets are also moving, which is a bit disturbing. There is a small part of the patch, which make to draw hairline primitive, when the line is solid (before only the width was checked). Maybe this part fixed the original bug, because as I see the hairline primitive means a solid line. Best regards, Tamás ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
