2013/6/7 Michael Stahl <mstahl@redhat.com>:
On 07/06/13 06:20, Markus Mohrhard wrote:
Hey,
so after some time I'm back at the border code to fix some problems
with the mappings between OOXML and Calc values.
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'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.
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.
Right now the only problem I see with this solution is that ODF's
border concept is similar to our current implementation and we would
need to find an acceptable mapping between values stored in ODF and
our limited border widths. However I hope that in the long run it
would simplify our code and improve the user experience.
i think that currently the borders UI is overly flexible; something
simpler is probably a good idea. like several line styles, and for each
line style several pre-defined widths that match what is commonly used
in MSO documents to get good interop there.
UI that allows setting arbitrary widths in 1 twip increments is really
overkill. we will perhaps get some complaints from users that have used
this flexibility in the past several LO versions but i'd hope there
aren't many who are really using this.
but we should have a bunch of predefined border styles for legacy OOo
compatibility in the UI in all applications.
perhaps also have different styles available in different applications;
for Word interop we need a lot more fancy styles that don't really make
sense in a spreadsheet; perhaps allow only one width per line style in Calc.
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.
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.
Regards,
Markus
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.