Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


Hi Michael,

On Thursday, 2012-01-26 18:21:16 +0100, Michael Stahl wrote:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=34315e7ec4062f9521cd19951b5f7f6ad9ce0d2e
Resolves https://bugs.freedesktop.org/show_bug.cgi?id=38595

ooh, Calc also has this kind of problem :)

Yup..

your fix is an improvement, but i have doubts about taking the width
from the fo:border at all if there is a style:border-line-width:

the idea is that for double borders, the 3 parts of
style:border-line-width should add up to the total width of the border;

Makes sense.

so if the fo:border contains a value different from the sum of the 3
parts then there is probably a problem.. i'd call such a document invalid.

but i suppose it would be legal to omit the width from fo:border for
double borders?

If I didn't misread
http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#border
7.29.3 "border"
[ <border-width> || <border-style> || <color> ] | inherit
then that would be valid, yes. Though IMHO we don't write that, but of
course another generator could.

what does this fix do then? initialize the width to zero?

If width was omitted then yes, the same effect as before when it was
overwritten with the style:border-line-width LineWidth member that is
zero.

i've fixed this differently in my patch for writer, which Cedric has
promised to review any minute now:
https://bugs.freedesktop.org/attachment.cgi?id=56151

It looks like it would be an improvement also for Calc if after both
attributes were read set LineWidth to the sum of outer,inner,space to
cope with omitted/different fo:border width.

However, there seem(s) to be some place(s) in the conversion to
SvxBorderLine where the constellation of LineWidth vs. outer,inner,space
is not taken into account. I didn't dig into yet, but it probably would
be convenient to have a conversion ctor from BorderLine2 instead of
letting every application figure that out..

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

Attachment: pgpdnqOTjU9Za.pgp
Description: PGP signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.