Date: prev next · Thread: first prev next last
2024 Archives by date, by thread · List index


Paul,

I don't /think/ your post relates to either the comment from Csongor or to the LibO Design minutes to which Csongor was 
responding, so I hope you will forgive this attempt to separate it from the "Minutes from the UX/design meeting 
2023-Jul-31", in the interest of both solving your problem and maintaining clarity with respect to the minutes. [If I 
have misjudged that premise, please correct me.]  I would suggest that this might be best addressed to the LibreOffice Users 
list <users@global.libreoffice.org> (a good list for sharing common problems and solutions), with a Subject line 
something like: "DOCX files rendered as black text on black background". [However, I have not added that list to 
this distribution, as it seemed too much presumption on my part; that is your call. I have also not modified the Subject 
line, though I think it is appropriate to do so.]

To be clear: Are you saying that, when you import a DOCX file, the text is rendered as black on a 
black background? (If so, let's begin by affirming that I never see that, so we can be pretty sure 
that this is not a LibreOffice design issue.) If that is not the issue, please clarify.

Also, does the phrase "monopolistic texts" refer to proprietary (MS or Apple) formats? Again, if 
not, please clarify.

Kind regards,
John


On 2024-08-01 10:53, paul hofseth wrote:
sirs,

I occasionally look at your dialogues and at times misguidedly complain about program stability rather than 
lack of "bells and whistles" .

I do realize that your task is dealing with the user interface and not with the data mechanics, but 
do hope that you have communication lines that concern program usefulness-.

This time I am sorely tempted to comment on the disability of reading monopolistic texts in docX 
format even if it lies outside your remit.

When working with our new book i have discovered a msjor annoyance when my co-authors use microsoft 
or apple. Black text on black background is not enlightening in any sense of the word.

p.

Den 01-08-2024 16:33, skrev Csongor Halmai:
Hi Heiko,

you wrote this:

   + necessary if the app DPI differs from the screen DPI (Csongor)

but I didn't say this.

I meant in my comment that this feature would be useful when you want to see more information than 
the resolution of your screen (and your eyes) allows. You could magnify the region of interest 
(ROI) while you still can see the big picture as well.

I created a mimicking screenshot in GIMP how I think it should look: 
https://i.ibb.co/WW0WsxC/magnifier-sample.png

Disclaimer: for the screenshot, I used the Spherize filter of GIMP, which is geometrically not 
identical to a magnifier lens but shows well enough what I would like to see.

In order to not hide anything from the underlying screen, it is essential that the center of the 
circle shows things larger than their original size but at the same time, around the edge, things 
look smaller. This way, the magnifier doesn't cover anything, just shows some distortion around the 
edges.

A realistic lens effect can be seen here: https://youtu.be/XtCW-axRJV8?t=271

I think this would be such a useful feature that it should be supported at operating system level.

Csongor




On 1/08/2024 04:56, Heiko Tietze wrote:
Present: Sahil, Eyal, Heiko
Comments: Mike, Justin, Stephane, Stuart, Cor

Tickets/Topics

(Suggested bump-up (Eyal):
  * Cell selecting fat border looks ugly especially if you selected some
    cell range, it also can block content in other cells
https://bugs.documentfoundation.org/show_bug.cgi?id=161709
    + Rafael: Made commits to improve the cosmetic situation, consider
      the bug fixed.
    + Rafael: This was done to resolve 143733, which requested the
      rectangle not cover the active cell
    + Heiko: Suggest accepting the current situation for now
    + Eyal: Serious degradation of UX - text in surrounding cells
      partially hidden, can make one value appear as another due
      to hiding.
    + Eyal: Suggest back-out of changes to before 143733, for now, and
      reconsideration. Must fix this for 24.8 release.
    + Eyal, Mihai, Rafael, Roman, flm2: Excel active cell rectangle looks
      nice
=> please discuss at Bugzilla or the mailinglists (Heiko)
)

  * No option to automatically indent multiline list entries to align
    with numbering followed by space
    + https://bugs.documentfoundation.org/show_bug.cgi?id=156071
    + line up *subsequent lines* of each list entry, see c12
    + no good example for the necessity (Mike, Cor, Heiko)
    + mandatory to have this as cross-platform feature (Justin, Cor)
    + A tab is, in the general sense, an inherently flawed solution,
      because once your number exceeds the tab width - you'll overflow
      and the alignment will be messed up (Eyal)
    + Request is reasonable (Eyal):
      + Follows a different aesthetic principle: Fixed amount of space
        between number and paragraph content v-start rather than uniform
        content v-start across all paragraphs
      + Should be implemented via a paragraph feature to move all lines
        further in to respect the maximum constraints on each individual
        line (e.g. numbering, wrapping around frames etc.), ensuring
        that the paragraph's v-start is uniform across all lines, without
        having to set it explicitly using indentation and/or tabs.
      + Should be usable even without numbering being active (an aspect
        of a paragraph's style)
    + requires probably also to start a list from any number (Heiko)
    + MSO does exactly the same as we do (Heiko)
    => comment

  * Tab stop of list contents increases then decreases in default
    Roman numeral list, looking messy
    + https://bugs.documentfoundation.org/show_bug.cgi?id=162133
    + Microsoft Office forces right alignment for Roman numerals, often
      with horrible results (Justin)
    + right-alignment is not the right solution => WF (Stephane, Cor)
  => solution follows bug 156071

 * PIVOTTABLE: Formating Pivot Tables
   + https://bugs.documentfoundation.org/show_bug.cgi?id=51732
   + double-click brings up the Data Field dialog currently, add
     a context menu (Stephane. Cor)
   + perhaps more obvious via push button? (Sahil)
   => provide a context menu for the functions

 * Magnifier Tool for a quick overview and spot zoom into a document
   in Multiple-page view
   + https://bugs.documentfoundation.org/show_bug.cgi?id=162101
   + magnifier is always just a click away, eg. Win + +/- on KDE
   + bug it does not render again with a higher resolution (Heiko)
   + "magnifier" would be an excellent feature *in general* (Stuart, Cor)
   + necessary if the app DPI differs from the screen DPI (Csongor)
   + duplicates / relates to bug 101646 "UI option "Scaling" was removed"
     with a lot duplicates itself
   + weird relation to multi-page view; suggest to do with low
     priority (Eyal)
   => comment



--
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy

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.