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

[Michael Stahl]

On 07/06/13 15:49, Markus Mohrhard wrote:
> 2013/6/7 Michael Stahl <mstahl at 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 :)