[Libreoffice-ux-advise] Proposal to limit border widths to 4 values

[Markus Mohrhard]

2013/6/7 Michael Stahl <mstahl at 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