On 07/06/13 15:49, Markus Mohrhard wrote: > 2013/6/7 Michael Stahl <mst...@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 :) _______________________________________________ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise