[Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document
bugzilla-daemon at bugs.documentfoundation.org
bugzilla-daemon at bugs.documentfoundation.org
Wed Jun 4 08:25:48 UTC 2025
https://bugs.documentfoundation.org/show_bug.cgi?id=166835
--- Comment #8 from Heiko Tietze <heiko.tietze at documentfoundation.org> ---
(In reply to Eyal Rozenberg from comment #3)
> It's the fact, for at least one change - the first format-breaking change,
> the user will be _fully_ aware of what they're doing...
Another example: You can direct format text as bold or via character style,
both are saved as <b> to HTML (and I would argue this is always DF). IOW, you
have a technical perspective on data and a user POV, depending on expertise and
workflow.
If you warn the first time about "styles are not stored with HTML" users might
not care but if it comes to another incompatibility they will for sure. So you
have to do it for every single attribute. Same argument in comment 5.
I doubt the use case of Benjamin loading an "extra format", something that is
not primarily suited for text processors or spreadsheet apps like html, rtf,
csv etc., expecting a different function set works the same way. Expert users
probably not invest "hours of working" ending up in being surprised on save.
When it comes to "similar formats" like odf - docx, we should rather aim for
100% compatibility - and still get into situations where the proprietary format
has its limitation.
More generally: Why do we always care about other applications? We should
proudly present our work and only secondarily consider other tools. User
running LibreOffice are supposed to work with ODF - period.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Libreoffice-ux-advise
mailing list