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
crucial feature:
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,
Gerald
Context
Re: [Libreoffice] [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167 · Christoph Noack
- Re: [Libreoffice] [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167 · Gerald Leppert
- (message not available)
- (message not available)
- (message not available)
- (message not available)
- (message not available)
- Re: [Libreoffice] [PUSHED] Fwd: [PATCH] Bug 39167 · Thorsten Behrens
Re: [Libreoffice] [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167 · Thorsten Behrens
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.