[Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=166835

--- Comment #11 from Eyal Rozenberg <eyalroz1 at gmx.com> ---
(In reply to Heiko Tietze from comment #8)
> 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 believe this is a similar concern as the one jan d raised: What constitutes
an "incompatible change"? Please see my reply to that in comment #10.


> 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.

I did not quite understand the end of this sentence. 

I will say that a 'Benjamin' user will likely not open plain text documents in
LO Writer. But it's not inconceivable Benjamin would open a CSV for editing in
Calc; or Markdown in Writer. And he may well do some formatting not supported
by the file format.

> Expert users probably not invest "hours of working" ending up in being 
> surprised on save.

That is partially true. If we don't think of Expert as a binary - it is quite
possible for a user to work on commented tracked change to a DOCX he got from a
collaborator, and only save his work after, say, an hour or two.

> 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.

First, this feature is not about _applications_, it is about file formats. It's
true that some formats are associated with applications, like DOCX, PPTX etc. 
But: CSV, TSV, plain text, Markdown, HTML - those are not app-associated.

Regardless - your point is a Red Herring. You see, this feature is only about
the case of editing non-ODF formats. When a user is editing an ODF file, or
creating a new file - this whole issue is irrelevant. This feature does not in
any way encourage _more_ work with non-ODF formats (nor less) - it's just about
what happens when users choose to edit them.

(In reply to Telesto from comment #9)
> I fully support this in principle. Would give more freedom, instead of
> constant compromising functions and such on foreign formats. And well file
> formats become probably less of an issue with cloud solutions.

Same point as I was making to Heiko. ODFs are great - but this bug is about
when you're editing other things. And some formats are just not that rich - nor
should they be. Would you suggest people use ODS instead of CSV or TSV for
unformatted tabular data? Or that Markdown is a useless format? Surely not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.