Hybrid PDF is one of the killer features of LibreOffice, but barely promoted and a bit hidden to the user. However, particularly the user experience can be easily improved. Easy Hack improvement of Hybrid PDF No. 2: When exporting a file to hybrid PDF, LibreOffice suggests as file extension “.pdf”. A clear improvement would be to use the file extensions “.odt.pdf”, “.ods.pdf”, “.odp.pdf”. This would be a great change of default settings benefitting end users for many reasons: 1st: The recipient of the hybrid PDF file recognizes it as such file. [and not guessing and trying to import every 'real' PDF file and getting frustrated by the result.] 2nd: It helps promoting this feature for LibreOffice's/ODF's visibility. 3rd: The creator of a hybrid PDF file usually does not want to hide the embedded odf-file. Given the “.pdf”-file extension, there is always the need to add an explanation that respective file actually contains an odf-file. In case, the author really would like to hide the existence of the embedded odf-file, he/she simply can rename the extension to only “.pdf”, but this should not be the default. Operating system integration: In a second step, LibreOffice should be added to the “Open With” dialogues of Linux, Windows, MacOS X for the file extensions “.odt.pdf”...
I am going to work on this issue, the solution for the first version of this problem will be published soon hopefully
I am half done with the problem, hopefully I'll be over for friday, so you can try other EasyHacks.
I am almost done with the problem, but I have the following problem: my rewritten version saves fine, it extends the names well and just if it's needed,but when I get warn on filename choosing dialog about existing file, it does not work well, as I modify the path just afterwards. But as it is both possible to choose ExportToPDF and Export choosing PDF, it's only possible to check when I have the final path, as in the second case HybridPDF dialog is only shown after setting the filename, so I need to eliminate this second method or I need to check afterwards and send a warn.
Hi. Gabor, I really hate to discourage you, but please note that I don't think that .odt.pdf's etc. are the way to go. * There is a Windows option called "hide known file extensions." While having been known as a security hole (you can make .exe's look like .txt's with a custom icon and a double file extension) for quite some time and having been turned off by default (I think! But as a non-regular Windows user this might be wrong) there will inevitably be lots of users who still have that option turned on. In other words: for some users .odt.pdf's will look like regular .odt's that for some reason open in their PDF reader and have a PDF icon (which is not expected behaviour, thus pretty bad). * Two file extensions look sneaky (see the .txt.exe case above) and awful (that's only my probably not-so-humble opinion). If I may make a suggestion, you could look into convincing the Evince/Okular/Sumatra developers (or whatever other (free) software you like to read PDF's with) to show an "Edit with LibreOffice" button or similar for hybrid documents (if LibO's installed). I will not close this bug now, but I would suggest that if someone else looks at this situation similarly to me, to do so.
Hi Aaron, thanks for your comment. The problem with the current hybrid PDF implementation is - as described above - that users simply don't know whether a file is a hybrid PDF or not. This renders the feature less useful than it could be and it can be even counterproductive in many cases (i.e. users who try to open 'real' PDF files in LibreOffice assuming that they are hybrid PDFs.). Hence, the proposal is to add ".od*.pdf" instead of only ".pdf". This small change would make the existence of hybrid PDFs visible to end users. This solution might look a bit sneaky, but what's alternative. By the way, that's exactly how it is handled in Papyrus (www.papyrus.de) where the idea of hybrid PDFs was first implemented. I don't understand the disadvantage of this enhancement for Windows users. Currently, they only see the filename and an PDF icon and they double-click on it. After this being enhanced, they see filename.odt and an PDF icon. Users now can choose whether they double click on it (which generally opens Acrobat) or whether they open it with LibreOffice. Users have the choice. I like you idea to have a "Edit in LibreOffice" button in Evince/Okular/Sumatra. However, this idea has two massive practical problems: First, almost all users on Windows and also many on Linux use Adobe Acrobat reader (and it is unlikely that Adobe implements an Edit with LibreOffice-button.). Second, there are lots of PDF viewers that share the remaining market share making the idea unlikely to succeed. I propose something different: Why not integrating the hybrid pdf feature with the operating system by adding a filetype and icon for ".od?.pdf"? The icon could look like half the LO icon and half the PDF icon. This would solve all problems and it even could lead to the ability to open hybrid pdfs with right mouse click "Open With" -> "LibreOffice".
A little addition to my previous comment about filetypes: It would make sense if the file extension ".od?.pdf" were associated with LibreOffice, of course. This would 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 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.
Created attachment 50023 [details] purposed patch This is a patch that resolves the issue, unfortunatelly the overwrite dialog pops up wrong. Since we had a great discussion about the problem on the list I wouldn't like to follow the development, so if someone fixes this tiny problem it would be appreciated, but I would mind with other problems now.
@gleppert: Your is locigal in the sense that a hybrid file format should have a hybrid (double) extension. But my test under winxp was not successful - a "some.other" extension overwrites the settings for the "other" extension. I have not tested on newer versions. If linking "od?.pdf" to one application and pure "pdf" under windows works (for doubleclick, etc) then I think your "double-extension" would be a realy great solution. Experienced user will understand and for non-experienced enduser the extension is meaningless - the only thing that counts is what happens on clicking to the file. In the meanwile - in my it is the "best compromise" I know. Another temporary way could be something like the "edit with ..." idea of astron, but the other way round: Register libreoffice as the primary pdf viewer and if it is not a hybrid pdf containing a odf document then delegate to another application. There should be a config option to select what app this is and at install time preconfigured with the existing standard pdf application.
(In reply to comment #4) > Hi. Gabor, I really hate to discourage you, but please note that I don't think > that .odt.pdf's etc. are the way to go. > So it seems we're still stuck at this - can we move the decision making to the ux-advise mailing list please? It is a pity that an otherwise useful patch is blocking here.
Thank you that you want to take this enhancement proposal and patch to the UX mailing list. As I explained in the developer mailing list a while ago and also in then comments to this bug, I think that .odt.pdf would be the (only) way to identify that the user deals with a hybrid pdf. Everything else makes the HybridPDF function a "hidden treasure" and the lack of any indication of HybridPDFs annoys in this regard that one tries to import non-hybrid PDFs into LibreOffice, which is a pain. The original idea of HybridPDF was taken from the programme Papyrus and they use .pap.pdf for quite some while. So why not doing the same? As I wrote in the the description of this bug: After implementing "clear and useful file extensions", the ideal world could also have some form of operating system integration, like "Open With LibreOffice". In any case, thanks a lot!
Created attachment 64739 [details] Example-file-1.pdf
Created attachment 64740 [details] Example-file-2.pdf
Little game to show the importance of "clear and useful file extensions": Which one is the HybridPDF? Is it attachment Example-file-1.pdf or attachment Example-file-2.pdf? ;-)
Reading the comments I can clearly see that changing the default extension to ".od?.pdf" and keeping the original ".pdf" both have challenges. I've been thinking of a possible work-around, perhaps using something similar to "-od?.pdf". If windows users hide file extensions then it would appear as "-od?", which does not imply a "-od?" file extension. That said, I feel that if a user chooses to hide extensions, then the extension should be hidden. For that reason, neither ".od?.pdf" nor "-od?.pdf" feel right, as the filename would have "?od?" at the end, which is not what the user chooses to see (and "-od?" just looks messy). Ideally, I'd like to have a totally different file extension, such as ".hpdf" and then magically have all the pdf readers associated to that extension, but that is impractical. Perhaps some more brainstorming is required on this subject. Maybe this discussion is best suited to the mailing lists.
The following would surely solve the double extension problem: 1) Use the MIME type ..PDF for all hybrid pdfs (eg. "MyHybridDocument..PDF") - this MIME type would designate a hybrid PDF as opposed to a normal PDF file. 2) Create a mini-app/tool that would open a ..PDF file and tell you what filetype and version is embedded with the PDF, as well as the application which created it. The mini-app/tool should probably be able to show a list of recommended apps to download and install in order to edit it (eg. OpenOffice and LibreOffice and others) and cloud apps that would be able to edit the file if local installation is not possible. The mini-app/tool should probably be web based so that app lists and new embedded formats can be easily updated - maybe a separate project should be set up for this, because it is likely to be much larger in scope than just OpenOffice/LibreOffice. 3) When an application opens a ..PDF file, it checks whether it can edit that type of file, opens it if it can and reports it cannot if it can't. 4) The ..PDF format would be open and infinitely extendable - for example the addition of other formats (probably by other projects) should be encouraged. The most likely candidates are Latex (professional non-WYSIWYG document typesetting), GNU Lilypond (music scores), Manpage format documents, DocBook format etc, so it is important that it is fully documented so that when others add other document format support, it is done in a compatible and interoperable way. Some neutral organisation should ideally maintain the mini-app/tool and the formats supported should probably be restricted to formats that are provided by at least one fully documented free and opensource app in order to avoid proprietary formats breaking its portability. Perhaps a GPL tie-in to the mini-app/tool that the format accesses in order to look up the embedded app type might be able to enforce that if the MIME type can be registered with the maintaining organisation in order to avoid proprietisation.
I am wondering whether anybody has thought about using real pdf attachments. For an example file see ftp://ftp.ctan.org/tex-archive/macros/latex/contrib/oberdiek/attachfile2.pdf. This gives the user awareness of the attachment and allows to discover it easily. All modern PDF readers display thess attachments.
(In reply to comment #16) > This gives the user awareness of the attachment and allows to discover it > easily. All modern PDF readers display thess attachments. Is all "modern PDF readers" another way of saying "just Adobe Reader, latest version"? (Ftr, I didn't see any indication of attachments in either of PDF.js, Sumatra PDF, Evince and Windows 8's preinstalled Reader application.)
Closing this as WONTFIX. A "double" file type extension is not very friendly to OS handling. As noted in comment 16, if work on bug 95328 is eventually done, embedded ODF documents will become visible "attachements" to our "Hybrd PDF" documents. That is sufficient.