[Libreoffice-ux-advise] [Bug 141292] Calc should display hint "internal calculation is done without rounding".
https://bugs.documentfoundation.org/show_bug.cgi?id=141292 --- Comment #20 from steffan.steff...@gmx.net --- (In reply to b. from comment #19) > it's two different problems ... > > one is the logical problem with rounding in totaling calculations, e.g the > conflict between selling two items for 1,02 bucks, each charged with 19 > percent VAT resulting in - rounded down - two times 0,19 -> 0,38, vs. > calculating the VAT for the full net amount of 2,04 bucks to - rounded up - > 0,39 is a problem a spreadsheet can't solve, the user must be aware that > there are pitfalls, check the correct way to calculate with his accountant, > and take that into account ... > > (spreadsheets can be set up correctly for each schema, but not for both at > the same time) Actually, in my case at hand, it would have been quite difficult to do the summing first, if there is 16% VAT on the first amount and 19% VAT on the second amount. Apart from that I completely agree that this is a well known problem, like i.e. here https://www.manager.io/guides/9499 But I think that most people would agree that in an invoice the numbers as displayed or "on paper" have to add up, even if this means that the result is mathematically less exact. The problem is that this case (see attachment "screenshot calculated in normal way" ) does not happen every day, so a person (like I) will be caught by surprise. Thus my request for a tooltip. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 141102] The "outline content visibility" feature deserves a friendlier name.
https://bugs.documentfoundation.org/show_bug.cgi?id=141102 Dieter changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #7 from Dieter --- VERIFIED with Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 807d059d99e7b99fe45a712428befa17ffa44858 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Jim, thanks for fixing it! -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 141292] Calc should display hint "internal calculation is done without rounding".
https://bugs.documentfoundation.org/show_bug.cgi?id=141292 b. changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #19 from b. --- it's two different problems ... one is the logical problem with rounding in totaling calculations, e.g the conflict between selling two items for 1,02 bucks, each charged with 19 percent VAT resulting in - rounded down - two times 0,19 -> 0,38, vs. calculating the VAT for the full net amount of 2,04 bucks to - rounded up - 0,39 is a problem a spreadsheet can't solve, the user must be aware that there are pitfalls, check the correct way to calculate with his accountant, and take that into account ... (spreadsheets can be set up correctly for each schema, but not for both at the same time) another problem is with which values calc calculates, and how much of it is visible / accessible to the user, that would have been quite easy for this case, but is a real pain once you get behind 14 digits, i vote for 'enhance this', -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 141211] Bold (or Italic) icon (in Formatting toolbar) should not be active when "Strong Emphasis" (or Emphasis) character style is applied
https://bugs.documentfoundation.org/show_bug.cgi?id=141211 --- Comment #11 from Mike Kaganski --- (In reply to sdc.blanco from comment #9) > For example, if custom CS “theoretical concept” has italic font, then > Formatting bar shows the italic icon toggled, but I cannot see in Formatting > (Styles) bar that I have applied a CS. ... which is likely a flaw of a tool on Styles toolbar, rather than of DF tool, right? -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 141211] Bold (or Italic) icon (in Formatting toolbar) should not be active when "Strong Emphasis" (or Emphasis) character style is applied
https://bugs.documentfoundation.org/show_bug.cgi?id=141211 --- Comment #10 from Mike Kaganski --- (In reply to sdc.blanco from comment #9) > (Not proposing any change here, just trying to understand the design > intention). Nice :-) > > > Presumably even if it makes life more complicated for non-DF users? > > > > Please explain how. > Formatting bar shows the state of formatting, regardless of whether DF or > applied by a style, so it is not always possible to use the toolbars to > decide immediately whether a style or a DF is being applied. > > For example, if custom CS “theoretical concept” has italic font, then > Formatting bar shows the italic icon toggled, but I cannot see in Formatting > (Styles) bar that I have applied a CS. You are holding this wrong :-) Your train of thought is like "it makes the use of DF toolbar more difficult for style users when they decide to use that toolbar for what it is not intended to do". So you basically start building expectations of a style user regarding tools not directly intended for them. This is wrong. Based on that reasoning, whenever you invent any tool for DF users, you inevitably come to a situation when a style user *could* in theory make use of such thing, *if* it were made differently - and so breaking the intended ease of use for DF users. Just don't do that! Now about the design intention. All DF tools are created *primarily* for users who do not use styles. For those users, the document does not consist of styled parts, it consists of characters having some formatting. And they might not care, or might not even know, where the formatting of a specific character comes from. Their tools must react predictably *at their level of thinking about document*, and that means that whenever a character is bold, the tool to control bold effect must suggest to unbold it - which implies that it is shown "activated" (=applied). Additionally, all DF tools work like paint: imagine a medieval painter who might decide to update (fix something on) an older painting. Instead of trying to remove everything from the old canvas at the changed site, they just paint over, masking whatever is beneath the new layer of the paint. That is an easy way for inexperienced users, and the tools designed for those users must be convenient for that mode of thinking. If you think that some tool on DF toolbar might be useful for style users if modified, and that modification is harmful for DF users, you are welcome to suggest a *new* tool e.g. on styles toolbar; it's wrong to think that not modifying the old tool "makes life more complicated for non-DF users", when their life is not more difficult now than it was before. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 141211] Bold (or Italic) icon (in Formatting toolbar) should not be active when "Strong Emphasis" (or Emphasis) character style is applied
https://bugs.documentfoundation.org/show_bug.cgi?id=141211 --- Comment #9 from sdc.bla...@youmail.dk --- (In reply to Mike Kaganski from comment #7) Perhaps I misunderstood / misinterpreted the relation between Formatting toolbar and Formatting (Styles) toolbar. Given that BZ has many assertions about the difference between DF and styles, it was surprising (unexpected) to see the DF (Formatting) bar “responding” to values set in styles. But I see now that all style settings are also reflected in the Formatting bar. > > Presumably even if it makes life more complicated for non-DF users? > > Please explain how. Formatting bar shows the state of formatting, regardless of whether DF or applied by a style, so it is not always possible to use the toolbars to decide immediately whether a style or a DF is being applied. For example, if custom CS “theoretical concept” has italic font, then Formatting bar shows the italic icon toggled, but I cannot see in Formatting (Styles) bar that I have applied a CS. (yes, i know, Style Inspector or Character Styles deck, but that is only immediate if it is always open) (Not proposing any change here, just trying to understand the design intention). -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
