On 07/06/13 15:49, Markus Mohrhard wrote:
2013/6/7 Michael Stahl <mstahl@redhat.com>:
On 07/06/13 06:20, Markus Mohrhard wrote:
I mentioned already the last time that in my opinion the only solution
in the end would be to limit the choice to 3 or maybe 4 values. Hair
line, thin, medium and thick which would improve interoperability with
MSO and hopefully make the UI a bit simpler. Right now we have an
unlimited number of border widths and together with all the
combinations of border style I doubt that we will ever get all cases
correct.
i'm afraid 4 values are not enough. would be ideal for MSO interop, but
we also want to interop with other ODF implementations; notably OOo and
AOO have a bunch of pre-defined border styles that may be used in lots
and lots of existing documents. users likely want to edit those
documents and then be able to add borders that look just like the ones
already in the document for consistency.
i think we'd probably need an extra border style "OOo legacy double
borders", because iirc those widths were weirdly asymmetric in some way.
I'm not talking about styles only about the border width. So mixing
different styles + width would still create a large number of
possibilities but we would limit to maybe 4 widths. At least before my
fix for some of the rendering issues Calc's UI was only able to show 4
different border widths between 0.05pt and 2 pts at 100%. Of course
zooming and printing changed the number of different widths that were
being displayed.
sure, screen has limited resolution. this may be more relevant for Calc
than Writer, since i'd guess spreadsheets are not printed as often.
I think that Writer had a similar limitation because the problem was
the drawinglayer border width calculation code but I might also be
wrong and it always worked in writer.
So from this point of view I think 4 or maybe if necessary 6 different
border width values are a good compromise between old behavior and new
one.
hmm... something like 6 width per style, sounds plausible...
I would just keep the width and style two orthogonal features. So we
would keep most/all of the styles that we currently support but limit
the number of different border widths that we support. At least from
my perspective the biggest problem is not the border style but the
border width which is based on some guessing + some strange
calculations with rounding errors.
unfortunately that's not how Word's borders work, there are different
widths for different styles.
Code wise I think it would solve many issues at once. Currently we
have several roundtrips between double and integer and calc and writer
use different units for border widths. These problems should hopefully
disapear with a limited number of fixed width borders.
hmm the different units problem is unlikely to disappear.
But we could use enumeration values for the border widths instead of
values that we need to map before calling the drawinglayer methods. So
at least for borders the widths would be totally defined in the
drawinglayer code and not every part of the code base would handle
border widths in an own unit and convert back to the drawinglayer
units.
that sounds like it would be an incompatible API change; so far you just
wanted to change the UI :)
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.