[Libreoffice-ux-advise] [Libreoffice] Fwd: [PATCH] Bug 39167
gleppert at gmx.de
Sat Aug 6 00:23:59 PDT 2011
Hi Christoph, hi all,
thank you very much for summarizing the HybridPDF request. Below your
summary I will add some thoughts.
> [...] * Hybrid PDFs are an important feature to him (option should be
> moved to the top)
> * The naming "hybrid" does not provide too much clues to the user
> (caption change proposed)
> * Identifying hybrid PDFs is close to impossible, because OS don't
> support that properly (file type name)
> * Opening hybrid PDFs for editing (again) is harder than necessary
> (recent files list) [...]
Good summary. However, in my opinion, the first point is not really
important. The second to fourth point, I think, are more important.
Particularly, the third point is really important as it causes confusion
and renders this feature less usable up to being counterproductive.
> * The name "Hybrid PDF" is indeed a bit technical. A different
> short name (e.g. "Combined PDF/ODF" or "Embed ODF source file")
> and revised description (advanced help) are indeed helpful -->
> but: for the dialog caption, please respect the text width
> required for translation
In bug 39167 Gabor proposes to use "Create LibreOffice fully editable
file". This sounds short enough and really easy to understand.
> * I don't know if hybrid PDFs are "one of the killer features",
> because ...
> * Portability: Conforming to standards like PDF/A-1a seems
> more important (in terms of arranging the options)
> * Size issue: PDFs are today used to deliver documents to
> mobile users (plain PDFs are still important)
> * Feature Set: Using hybrid PDFs removes the "export page
> range" feature
Let me describe more in detail why I am sure that HybridPDF is a very
In professsional or academic environments an everyday standard scenario
is that you receive and send documents (via email or other channels).
When receiving a file, im most cases you want to read it and in some
cases you want to make changes or review it. When you send a file, you
must get sure that your counterpart can at least perfectly read the
file. However, the main problem is that you generally don't know what
software the counterpart uses. As you know, the standard exchange
formats are still .doc(x), .ppt(x), .xls(x), if you like it or not.
The result is the typical 'negative network effect' that hinders many
people using LibreOffice in professional environments. Why? If you send
MS formats, you better use Microsoft Office yourself, because
LibreOffice too often has only a 99% compatability with these formats.
If you send OpenDocument files, the counterpart either responds that
he/she cannot open the attachment or - even worse- he/she thinks that
there was not meaningful attachment and drops the email at all.
What is the only easily doable solution for this problem? In my
opinion, HybridPDF. If this feature were properly implemented and also
the filetype ".od*.pdf" registered with the operating system, it lead to
the perfect situation that people who have LibreOffice on the computer
could directly edit the file when double-clicking on it. And, people who
have no LibreOffice installed on the system, would simply see the file
in the default PDF viewer. The ultimate result of this would be that no
user has to worry about sending ODF-files to his/her counterpart in the
'fear' that the counterpart cannot open ODF-files at all. These
interoperability problems are the main hindrance for the expansion of
the OpenDocument format.
Of course, I understand the limitations of HybridPDFs in terms of
portability, size issue and feature set, as you described it above.
> [...] * The current hybrid option requires the PDF import extension -
> being optional (although being shipped on e.g. Windows) makes it
> a less important option
If thoroughly considered, it would make sense to have the hybridPDF-part
of the extension in the default install set.
> * There is a major difference for the user between "exporting
> documents" (editing in LibO causes major loss in fidelity / is
> impossible) and "saving files" (runs smoothly) --> your
> proposals would require LibreOffice to treat hybrid PDFs similar
> to native file formats
> * Opening of a (non-hybrid/hybrid) PDF should be possible
> in any application. If it is a non-hybrid PDF, then
> inform the user that it gets imported in Draw; if its a
> hybrid PDF, then simply open it
> * Re-opening a hybrid PDF and saving it again should
> create an updated version of the hybrid PDF
> * If possible: if a hybrid PDF gets saved, then inform the
> user about the consequences (might look like a normal
> PDF, size, ...)
> * Side note: for the hints, the non-modal information bars
> would again be helpful
Yes, if everyone agreed to the core opportunities of HybridPDF, this
would lead to treat it similar to native file formats. (However, I did
not dare to propose it myself :-)
> * I share the concerns stated by the others with regard to the
> ".od?.pdf" file extension - especially since most people might
> still not know what the "od?" stands for. I'm unsure about the
> real impact. An alternative may be to change the given file name
> to something like "-embeddedODF.pdf". Users might then consider
> to change that manually ...
If I understand your idea correctly, then you propose to use the file
endings ".embeddedOD?.pdf" instead of ".od?.pdf"? Sounds good to me.
This would be a solution to three problems: Firstly, windows users would
not be confused by files called "filename.odt" with a PDF icon.
Secondly, users could identify the existence of a hybridPDF. Thirdly, it
would be possible to integrate HybridPDF file types into the operating
system resulting in: double click opens LO if installed. Or, double
click opens PDF viewer, if LO is not installed.
Kind regards and have a nice weekend,
More information about the Libreoffice-ux-advise