Problem description: Hybrid PDF is a great file format that would solve a lot of issues for offices sending documents to others. However, it's use is difficult to implant as an habit for workers by being an export option instead of a save option. My proposal is that Hybrid PDF is offered as yet another document format to the Save command and even allowing making it default. From a formal point of view, since an Hybrid PDF file can be opened in LibreOffice Writer exactly the same as an ODT file, it shouldn't belong to the export option. Current behavior: The user needs to go through the process of exporting and avoiding the standard saving mechanisms, which is odd and cumbersome and makes it hard for it to become a desirable habit. Expected behavior: Hybrid PDF should be like any other document format, working on every Save/Save As/Save a Copy/etc. commands. Operating System: All Version: 4.2.4.2 release
Not sure this makes sense, or is even feasible, but setting an enhancement. We are going to need specifics of the proposal. For example, as the native ODF standards (on which the LibreOffice documents are based and processed) provide no interoperability with PDF, is there a technical description or API for this "Hybrid PDF" format? How would its implementation compare with overdue support for PDF standards--ISO 32000-1 for PDF 1.7, or of ISO 14289-1 for PDF/UA? Correct filtered Cairo project based "print" export to PDF formats and filtered import into ODF as ODG is the existing architecture. How would document fidelity be assured on round trips into and out of this "Hybrid PDF" format? Please flesh it out including references, and attach any documentation to BZ this issue.
(In reply to comment #0) > Problem description: > > Hybrid PDF is a great file format that would solve a lot of issues for > offices sending documents to others. No, it is not. It is just a workaround to make PDF suck less. For interoperability, we have this OASIS standard called ODF. > However, it's use is difficult to > implant as an habit for workers by being an export option instead of a save > option. It is not difficult at all. All one needs is to click on the "Export to PDF" icon on toolbar. > > My proposal is that Hybrid PDF is offered as yet another document format to > the Save command and even allowing making it default. I strongly disagree. > > From a formal point of view, since an Hybrid PDF file can be opened in > LibreOffice Writer exactly the same as an ODT file, it shouldn't belong to > the export option. Wrong. A hybrid PDF is still a PDF. Also, there is _no way_ to differentiate a hybrid PDF from normal PDF except opening it, So these files would not be listed in open dialog. > > Current behavior: > The user needs to go through the process of exporting and avoiding the > standard saving mechanisms, which is odd and cumbersome and makes it hard > for it to become a desirable habit. It is no more cumbersome than normal save. > > Expected behavior: > Hybrid PDF should be like any other document format, working on every > Save/Save As/Save a Copy/etc. commands. I can already imagine uninformed users trying to use export to PDF instead of normal save in other applications, "because it works in LibreOffice", and losing their work...
(In reply to comment #1) > Not sure this makes sense, or is even feasible, but setting an enhancement. > > We are going to need specifics of the proposal. > > For example, as the native ODF standards (on which the LibreOffice documents > are based and processed) provide no interoperability with PDF, is there a > technical description or API for this "Hybrid PDF" format? > > How would its implementation compare with overdue support for PDF > standards--ISO 32000-1 for PDF 1.7, or of ISO 14289-1 for PDF/UA? > > Correct filtered Cairo project based "print" export to PDF formats and > filtered import into ODF as ODG is the existing architecture. How would > document fidelity be assured on round trips into and out of this "Hybrid > PDF" format? > > Please flesh it out including references, and attach any documentation to BZ > this issue. It looks like you don't even know the existence of an Hyrid PDF export option. Please check the info on that option at the Export PDF command.
(In reply to comment #2) > (In reply to comment #0) > > Problem description: > > > > Hybrid PDF is a great file format that would solve a lot of issues for > > offices sending documents to others. > > No, it is not. It is just a workaround to make PDF suck less. For > interoperability, we have this OASIS standard called ODF. Yes it is. And no, it's not a workaround whatsoever. It's a sane option to keep a whole office on PDF avoiding the current mess of sending editable documents out of the office. Your tone hardly invites civil discussion but I'll try. > > > However, it's use is difficult to > > implant as an habit for workers by being an export option instead of a save > > option. > > It is not difficult at all. All one needs is to click on the "Export to > PDF" icon on toolbar. It is indeed very difficult for a whole office of workers to use export instead of save EVERY TIME. It's also difficult to ignore the saving function altogether, because the goal is using Hybrid PDF as the single format inside an organisation. > > > > > My proposal is that Hybrid PDF is offered as yet another document format to > > the Save command and even allowing making it default. > > I strongly disagree. That's obvious, but you have yet to explain why. > > > > > From a formal point of view, since an Hybrid PDF file can be opened in > > LibreOffice Writer exactly the same as an ODT file, it shouldn't belong to > > the export option. > > Wrong. A hybrid PDF is still a PDF. Also, there is _no way_ to differentiate > a hybrid PDF from normal PDF except opening it, So these files would not be > listed in open dialog. Wronng. A Hybrid PDF is a PDF+ODF file. No way to differentiate both is irrelevant. This is a case for "an internal format for an organisation that happens to be easy to send out and easy to edit when inside the organisation. No duplication of files ever". > > > > > Current behavior: > > The user needs to go through the process of exporting and avoiding the > > standard saving mechanisms, which is odd and cumbersome and makes it hard > > for it to become a desirable habit. > > It is no more cumbersome than normal save. It is indeed. > > > > > Expected behavior: > > Hybrid PDF should be like any other document format, working on every > > Save/Save As/Save a Copy/etc. commands. > > I can already imagine uninformed users trying to use export to PDF instead > of normal save in other applications, "because it works in LibreOffice", and > losing their work... I don't follow this logic. LibreOffice only has to show "This PDF is not Hybrid and can't be edited in Writer" when a user trys to open (not import) a PDF. That won't happen with internal documents but will probably happen with many external ones. Besides, nothing prevents HybridPDFs to be shown with a different icon so you know which are Hybrid and which aren't. Just ouf of curiosity: what's your opinion on Hybrid PDFs? You just seem to hate them for no reason. Your overly agressive reply is way out of line.
(In reply to comment #4) > > > My proposal is that Hybrid PDF is offered as yet another document format to > > > the Save command and even allowing making it default. > > > > I strongly disagree. > > That's obvious, but you have yet to explain why. All right, so just from the top of my head (so in a random order or importance): * It is _slow_. I mean really slow: export to PDF is easily 10 times slower than save to ODF. Import is slower too, for technical reasons that cannot easily be changed. * (I have already said that, but...) There is no way to differentiate between normal and hybrid PDFs when looking at directory listing. * Worse yet, there is no way to differentiate between different types of documents (text, presentations, spreadsheets, ...) That is a major usability regression compared to using ODF. * It effectively means that we are creating a new document format, not supported by anyone else. There is already too many different file formats. (This alone is a deal breaker for me.) * It duplicates functionality. * It creates the perception of PDF as an editable format, which it is not. I am sure I could come with a few more if I really thought about it. > > > > > > From a formal point of view, since an Hybrid PDF file can be opened in > > > LibreOffice Writer exactly the same as an ODT file, it shouldn't belong to > > > the export option. > > > > Wrong. A hybrid PDF is still a PDF. Also, there is _no way_ to differentiate > > a hybrid PDF from normal PDF except opening it, So these files would not be > > listed in open dialog. > > Wronng. A Hybrid PDF is a PDF+ODF file. No way to differentiate both is > irrelevant. It is very much relevant from usability POV. If I have a directory full of PDFs, the only way to discover which ones I can edit and which can only be imported is to actually try to open them. > > > > > > Expected behavior: > > > Hybrid PDF should be like any other document format, working on every > > > Save/Save As/Save a Copy/etc. commands. > > > > I can already imagine uninformed users trying to use export to PDF instead > > of normal save in other applications, "because it works in LibreOffice", and > > losing their work... > > I don't follow this logic. LibreOffice only has to show "This PDF is not > Hybrid and can't be edited in Writer" when a user trys to open (not import) > a PDF. That won't happen with internal documents but will probably happen > with many external ones. This was not about LibreOffice at all. I was talking about uninformed users being misled into belief that PDFs can be edited in LibreOffice and losing their work created in _other_ applications as a consequence. > Besides, nothing prevents HybridPDFs to be shown > with a different icon so you know which are Hybrid and which aren't. Nothing except the fact that the only way to recognize a hybrid PDF is to open it. That is slow even locally if there is more than a few dozens of files, not mentioning doing it for a remote folder. Also, this would only work in LibreOffice's internal file dialog, not if the system one is used. > > Just ouf of curiosity: what's your opinion on Hybrid PDFs? You just seem to > hate them for no reason. Your overly agressive reply is way out of line. I have nothing about hybrid PDF. I recognize its value for having a PDF export of a document that can still be opened for editing, if necessary. But it is still a PDF and nothing is going to change that.
2014-07-20 15:52 GMT+02:00 <bugzilla-daemon@freedesktop.org>: > *Comment # 5 <https://bugs.freedesktop.org/show_bug.cgi?id=79811#c5> on > bug 79811 <https://bugs.freedesktop.org/show_bug.cgi?id=79811> from David > Tardon <dtardon@redhat.com> * > > (In reply to comment #4 <https://bugs.freedesktop.org/show_bug.cgi?id=79811#c4>)> > > My proposal is that Hybrid PDF is offered as yet another document format to > > > > the Save command and even allowing making it default. > > > > > > I strongly disagree. > > > > That's obvious, but you have yet to explain why. > > All right, so just from the top of my head (so in a random order or > importance): > > * It is _slow_. I mean really slow: export to PDF is easily 10 times slower > than save to ODF. Import is slower too, for technical reasons that cannot > easily be changed. > > I'm not advocating for Hybrid PDF to become a default saving format. All its drawbacks are up to the user, including this one. > * (I have already said that, but...) There is no way to differentiate between > normal and hybrid PDFs when looking at directory listing. > > This can be easily implemented. Since the format is being created inside LIbreOffice, it can be marked as HybridPDF in the corresponding place in the file. BTW, all of this is irrelevant to my point: whether the Hybrid PDF is created via "Save as..." or "Export" doesn't change this issue. > * Worse yet, there is no way to differentiate between different types of > documents (text, presentations, spreadsheets, ...) That is a major usability > regression compared to using ODF. > > As I said, this is easily solvable and it would apply exactly the same to Hybrid PDF as export. > * It effectively means that we are creating a new document format, not > supported by anyone else. There is already too many different file formats. > (This alone is a deal breaker for me.) > > So what? It's not like ODF is being supported by everyone. Besides, there's a good reason to use a Hybrid PDF for certain organizations, as I've pointed out already. > * It duplicates functionality. > > Again, so what? All of the formats "duplicate functionality" in some way. Hybrid PDF can earn a place among other file formats for reasons I have already explained. > * It creates the perception of PDF as an editable format, which it is not. > > As long as you make it visibly different (by saving the right bits to identify such Hybrid PDF files) there won't be such perception at all. > I am sure I could come with a few more if I really thought about it. > > If they're are as strong as the previous ones, you are actually supporting my point... > > > > > > > > From a formal point of view, since an Hybrid PDF file can be opened in > > > > LibreOffice Writer exactly the same as an ODT file, it shouldn't belong to > > > > the export option. > > > > > > Wrong. A hybrid PDF is still a PDF. Also, there is _no way_ to differentiate > > > a hybrid PDF from normal PDF except opening it, So these files would not be > > > listed in open dialog. > > > > Wronng. A Hybrid PDF is a PDF+ODF file. No way to differentiate both is > > irrelevant. > > It is very much relevant from usability POV. If I have a directory full of > PDFs, the only way to discover which ones I can edit and which can only be > imported is to actually try to open them. > > OK. You're right. H-PDF should be recognizable. That's true both for "Export" as "Save as...". Remember I'm asking here for H-PDF to become a "saveable" format, for reasons well explained (I want the organizations supported by me to use it by default, which isn't possible with the "Export" option). Again, this is easily done when saving the file. Just write the right bits to make it recognizable by the OS. An H-PDF should be shown as a standard PDF when LibreOffice is not installed on the computer. > > > > > > > > > Expected behavior: > > > > Hybrid PDF should be like any other document format, working on every > > > > Save/Save As/Save a Copy/etc. commands. > > > > > > I can already imagine uninformed users trying to use export to PDF instead > > > of normal save in other applications, "because it works in LibreOffice", and > > > losing their work... > > > > I don't follow this logic. LibreOffice only has to show "This PDF is not > > Hybrid and can't be edited in Writer" when a user trys to open (not import) > > a PDF. That won't happen with internal documents but will probably happen > > with many external ones. > > This was not about LibreOffice at all. I was talking about uninformed users > being misled into belief that PDFs can be edited in LibreOffice and losing > their work created in _other_ applications as a consequence. > > This -once more- is a problem both for saving and exporting. I've suggested a solution to this issue already. > > Besides, nothing prevents HybridPDFs to be shown > > with a different icon so you know which are Hybrid and which aren't. > > Nothing except the fact that the only way to recognize a hybrid PDF is to open > it. That is slow even locally if there is more than a few dozens of files, not > mentioning doing it for a remote folder. Also, this would only work in > LibreOffice's internal file dialog, not if the system one is used. > > Files are recognized by some sort of "magic number" written to the file. You can do that for Hybrid PDFs the same you do for evey other type file. On Windows, you would rely on the file's extension. I don't have a solution to that (I'm not a Windows user), but -again- that's a "problem" for both exporting and saving. I'm asking here for a saving mechanism for the H-PDF format, as opposed to exporting only, for reasons clearly explained. > > > > Just ouf of curiosity: what's your opinion on Hybrid PDFs? You just seem to > > hate them for no reason. Your overly agressive reply is way out of line. > > I have nothing about hybrid PDF. I recognize its value for having a PDF export > of a document that can still be opened for editing, if necessary. But it is > still a PDF and nothing is going to change that. > > Actually, it's not "still a PDF". It's more than that and that's why it exists. I'm just asking for it to be "saveable", instead of "exportable". A file that can be edited by LibreOffice should be both "saveable" and "openable", not just "exportable" and "importable". Most of your issues are with the format itself. You're not addressing the point of this bug report, which is "make it saveable" instead (or in addition to) "exportable".
I'm sorry for the formatting. The first line of each of my replies has been posted as if it was part of the original posting. Don't know exactly why. Al
(In reply to comment #6) > > * (I have already said that, but...) There is no way to differentiate between > > normal and hybrid PDFs when looking at directory listing. > > > This can be easily implemented. Since the format is being created inside > LIbreOffice, it can be marked as HybridPDF in the corresponding place in > the file. Where exactly is that? I am not aware of any special support in PDF to create "subformats" (granted, I do not know details of PDF structure...) Also, doing this immediately invokes the part about creating new format... > BTW, all of this is irrelevant to my point: whether the Hybrid > PDF is created via "Save as..." or "Export" doesn't change this issue. There is a big difference in perception. For export, hybrid PDF is a (immutable) PDF that just happens to contain the original document. So it does not matter that it is indistinguishable from a normal PDF. For save, the format becomes a (mutable) document format, and the PDF is a "container" and a "preview" in one. > > > * It effectively means that we are creating a new document format, not > > supported by anyone else. There is already too many different file formats. > > (This alone is a deal breaker for me.) > > > So what? It's not like ODF is being supported by everyone. And it will never be if we start creating new formats whenever someone asks for them. > Besides, > there's a good reason to use a Hybrid PDF for certain organizations, as > I've pointed out already. That some organizations could find it convenient is not a compelling enough reason to create a new file format. A format that, by the way, is in most ways inferior to ODF: saving/loading takes longer, the files are bigger, it is not supported by any other application... > > * It creates the perception of PDF as an editable format, which it is not. > > > > As long as you make it visibly different (by saving the right bits to > identify such Hybrid PDF files) there won't be such perception at all. Which are these "right bits"? Also, the extension will still be pdf. So, to avoid any such problems, it would have to become widely supported by operating systems. Not mentioning that type detection typically considers the extension alone, because any peeks into the files are costly and would make listing of directories with larger number of files unacceptably slow. > Again, this is easily done when saving the file. Just write the right bits > to make it recognizable by the OS. An H-PDF should be shown as a standard > PDF when LibreOffice is not installed on the computer. > Files are recognized by some sort of "magic number" written to the file. Yes, and for PDF that magic number identifies a PDF. The ODF is saved inside an object stream, which is only interpreted on loading. > Most of your issues are with the format itself. You're not addressing the > point of this bug report, which is "make it saveable" instead (or in > addition to) "exportable". No, my issues illustrate why it is a bad idea to "make it saveable".
Btw, I would have no problem doing this the other way: i.e., allowing to save PDF export into ODF as an alternative representation of the content (provided, that ODF supports that. I am not sure. I know EPUB can do it, but I would have to check for ODF.)
I'm sorry but your arguments either lack basic logic reasoning, are ignoring my replies altogether or are your pure personal opinions (which I won't discuss, obviously). You are constantly mixing arguments against the Hibryd-PDF format instead of arguing against my particular proposal: "save instead of (or in addition to) export". The Hybird-PDF format is already here. Thanks God there's no need to argue with you about that. Now I hope other people in LO come to read this and find my use case reasonable. I have explained all that's needed and I don't believe further discussing this with you is constructive at all. Let me suggest you again to face proposals without hostility. There's absolutely no need for that.
(In reply to comment #10) > I'm sorry but your arguments either lack basic logic reasoning, are > ignoring my replies altogether or are your pure personal opinions (which I > won't discuss, obviously). I am sorry too, but your only argument so far has been "some people could find this convenient" (which is a personal opinion, btw). Handwawy "this-or-that can easily be solved" as response to pointed problems with your proposal is not an argument, _unless_ you show the solution too. And trying to marginalize my arguments by saying that they lack basic logic reasoning suggests you do not actually have any answers. Btw, could you tell me which of my replies lack basic logic reasoning, which are ignoring your replies and which are personal opinions? > You are constantly mixing arguments against the > Hibryd-PDF format instead of arguing against my particular proposal: "save > instead of (or in addition to) export". I think you have not read my response... Or are ignoring it. I will not repeat it again. > > The Hybird-PDF format is already here. Thanks God there's no need to argue > with you about that. That is the main point I tried to convey and you are unable (or unwilling) to understand: what we call hybrid PDF is not a separate format. It differs from normal PDF in a single way: somewhere inside the file there is an object stream whose content is the original ODF. This does not make the PDF special in any way. Object streams are normal feature of PDF: images are saved that way, for example. IOW, as I have already repeated ad nauseam: the only way to differentiate hybrid PDF from a normal one is to process it. There are no special "bits" in the file header. A hybrid PDF _is_ a PDF. > Now I hope other people in LO come to read this and find my use case > reasonable. I have explained all that's needed and I don't believe further > discussing this with you is constructive at all. I do not believe there is anything more to discuss either. > Let me suggest you again > to face proposals without hostility. There's absolutely no need for that. Let me suggest you to face counter-arguments without being opinionated. There is absolutely no need for that.
I thought you were just trolling, but I've searched a little bit and you actually have some responsibility in the development of LibreOffice. That's sad, and also sadly reflects the much commented "arrogant attitude of FLOSS developers". Hopefully you're not in charge of UX design (which is what this is all about, despite your diatribes about the Hybrid PDF format which are completely unrelated to the proposal). Hopefully, again, someone concerned with usability will understand my proposal and go about it constructively. I have nothing more to discuss with you. 2014-07-20 22:41 GMT+02:00 <bugzilla-daemon@freedesktop.org>: > *Comment # 11 <https://bugs.freedesktop.org/show_bug.cgi?id=79811#c11> > on bug 79811 <https://bugs.freedesktop.org/show_bug.cgi?id=79811> from > David Tardon <dtardon@redhat.com> * > > (In reply to comment #10 <https://bugs.freedesktop.org/show_bug.cgi?id=79811#c10>) > > I'm sorry but your arguments either lack basic logic reasoning, are > > ignoring my replies altogether or are your pure personal opinions (which I > > won't discuss, obviously). > > > I am sorry too, but your only argument so far has been "some people could find > this convenient" (which is a personal opinion, btw). Handwawy "this-or-that can > easily be solved" as response to pointed problems with your proposal is not an > argument, _unless_ you show the solution too. And trying to marginalize my > arguments by saying that they lack basic logic reasoning suggests you do not > actually have any answers. > > Btw, could you tell me which of my replies lack basic logic reasoning, which > are ignoring your replies and which are personal opinions? > > > You are constantly mixing arguments against the > > Hibryd-PDF format instead of arguing against my particular proposal: "save > > instead of (or in addition to) export". > > > I think you have not read my response... Or are ignoring it. I will not repeat > it again. > > > > > The Hybird-PDF format is already here. Thanks God there's no need to argue > > with you about that. > > > That is the main point I tried to convey and you are unable (or unwilling) to > understand: what we call hybrid PDF is not a separate format. It differs from > normal PDF in a single way: somewhere inside the file there is an object stream > whose content is the original ODF. This does not make the PDF special in any > way. Object streams are normal feature of PDF: images are saved that way, for > example. IOW, as I have already repeated ad nauseam: the only way to > differentiate hybrid PDF from a normal one is to process it. There are no > special "bits" in the file header. A hybrid PDF _is_ a PDF. > > > Now I hope other people in LO come to read this and find my use case > > reasonable. I have explained all that's needed and I don't believe further > > discussing this with you is constructive at all. > > > I do not believe there is anything more to discuss either. > > > Let me suggest you again > > to face proposals without hostility. There's absolutely no need for that. > > > Let me suggest you to face counter-arguments without being opinionated. There > is absolutely no need for that. > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > - You reported the bug. > >
I'd like to add this article that supports my point: http://blogs.computerworlduk.com/simon-says/2012/03/the-magic-of-editable-pdfs/index.htm From a usability point of view, using Export instead of Save is a burden for an office environment wanting to adopt the scenario described in the article.
I also want to add a suggestion by a forum poster from as early as 2008: https://forum.openoffice.org/en/forum/viewtopic.php?t=2426#p33839 "For example by giving it an extension .o.pdf or .odt.pdf , .ods.pdf etc. Without this, you can't easily tell what file you saved as a hybrid PDF and what as a PDF." That would solve very easily the eventual problem of differentiating "pure PDF" files from Hybrid PDF files in a given folder.
(In reply to comment #12) > I thought you were just trolling, but I've searched a little bit and you > actually have some responsibility in the development of LibreOffice. That's > sad, and also sadly reflects the much commented "arrogant attitude of FLOSS > developers". http://en.wikipedia.org/wiki/Troll_(Internet) : "In Internet slang, a troll is a person who sows discord on the Internet by starting arguments or upsetting people,[1] by posting inflammatory,[2] extraneous, or off-topic messages in an online community with the deliberate intent of provoking readers into an emotional response[3] or of otherwise disrupting normal on-topic discussion." I would say that the above comment of yours fits pretty well... > Hopefully you're not in charge of UX design (which is what > this is all about, despite your diatribes about the Hybrid PDF format which > are completely unrelated to the proposal). Yes. And I have tried to explain some of the UX conseqences of the change. Either I have failed or you do not want to understand.
(In reply to comment #13) > I'd like to add this article that supports my point: > http://blogs.computerworlduk.com/simon-says/2012/03/the-magic-of-editable- > pdfs/index.htm It does not. All it says that, in case there is a need to edit a PDF, it is good if it contains the original document. Nobody has been contesting that.
(In reply to comment #14) > "For example by giving it an extension .o.pdf or .odt.pdf , .ods.pdf etc. > Without this, you can't easily tell what file you saved as a hybrid PDF and > what as a PDF." > > That would solve very easily the eventual problem of differentiating "pure > PDF" files from Hybrid PDF files in a given folder. Yes, but it is only a half of a solution. It only works in libreoffice (and possibly only if the internal file dialog is used, which is mostly not--the use of system file dialog is the default on all platforms. And it would need a special handling, as we do not expect double extension anywhere, but that is a solvable detail.)
Wow - what a long bug; from a product perspective - I think Aleve is right - this would be a great feature. I agree its practically extremely problematic =) no doubt about it; but I'd like to have this guy as a placeholder for this feature I think we will need (eventually).
It's long only because someone decided to make a lot of noise about nothing, which is sadly too frequent in FLOSS projects. The proposal is pretty simple and its implementation isn't "extremely problematic" whatsoever. Exporting or saving is just a decision regarding the UI (usually, formats that the app itself can edit are put into "save" and the rest are put into "export", although some projects have a somewhat different approach, like GIMP for instance). All the work has been done on the format itself, so it's just about placing an option in the save dialog instead of -or in addition to- the export dialog. (Now expect a new reply from the noise maker. Guaranteed...)
@Aleve, *, If David T. chooses to respond or not is not relative to whether this suggested UX enhancement merits developer effort. What is germane is that the PDF import filter cleanly handles conversion both on opening and when exporting to PDF--it is not implemented as an ODF document save-as format. Also, there ARE standards for creation of PDF. As there are standards for ODF. And that the Hybrid PDF implemented by Sun Microsystems in the PDF Import Extension--now incorporated into LibreOffice core--is not a standard in any sense. It is a kludge that is only marginally supported by the LibreOffice suite and not by Apache OpenOffice at all. A check-box during export to PDF is probably all the more support that should be provided, the "PDF/ODF Hybrid File" is NOT an interoperability solution and should not be treated as such. Regards PDF, frankly there are more substantive requirements in the correct handling of PDF that the project must address as a priority far more pressing than this novelty. Such as the correct generation of tagged PDF, and of PDF/A archival formats, as well as in implementing support for ISO 32000-1 for PDF 1.7. Or even addressing the current total lack of support for ISO 14289-1 and PDF/UA. And to my mind any of these standards as enhancements that would be worth developer cycles. Of course you are welcome to attempt to code the transition from export check box, to non-native save-as option yourself. Not the first project I'd want to tackle. Stuart
> The proposal is pretty simple and its implementation isn't "extremely > problematic" whatsoever. Looking forward to your patch =) The mental notes I have (at a minimum) would be re-factoring the UI for PDF export, (eg. resolution of images etc.) so that these become options of the hybrid PDF file, so when you re-save they are re-applied, and when you want to change that you can [ just as a start ]. Then of course, the performance problems, duplication of data in PDF and ODF containers etc. etc. are all rather susceptible to some work. Perhaps a couple of weeks of work for a determined beginner - happy to give some code pointers if you want to get stuck in :-)
I think we can close this bug report as WONTFIX. Please don't try to make PDF format an editable format, you will only confuse the user. Think that you can't distinguish between PDF, PDF archive and PDF hybrid. About save vs. export: I think (I already made this proposition) that LO should save / save_as in ODF only and export in all other formats, including OOXML. Best regards. JBF
Just out of curiosity: are there actual designers and UX experts working on LO or is it just coders? This blindness to what's good for users (or lame "code it yourself" replies) can hardly come from professional UX desginers. If there are indeed people in charge of this product and its users needs, can someone be so kind to let me know their names? 2014-08-06 8:55 GMT+02:00 <bugzilla-daemon@freedesktop.org>: > Jean-Baptiste Faure <jbf.faure@sud-ouest.org> changed bug 79811 > <https://bugs.freedesktop.org/show_bug.cgi?id=79811> > What Removed Added Status NEW RESOLVED Resolution --- WONTFIX CC > jbf.faure@sud-ouest.org > > *Comment # 22 <https://bugs.freedesktop.org/show_bug.cgi?id=79811#c22> > on bug 79811 <https://bugs.freedesktop.org/show_bug.cgi?id=79811> from > Jean-Baptiste Faure <jbf.faure@sud-ouest.org> * > > I think we can close this bug report as WONTFIX. Please don't try to make PDF > format an editable format, you will only confuse the user. Think that you can't > distinguish between PDF, PDF archive and PDF hybrid. > > About save vs. export: I think (I already made this proposition) that LO should > save / save_as in ODF only and export in all other formats, including OOXML. > > Best regards. JBF > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > - You reported the bug. > >
(In reply to comment #23) > Just out of curiosity: are there actual designers and UX experts working on > LO or is it just coders? This blindness to what's good for users (or lame > "code it yourself" replies) can hardly come from professional UX desginers. Since you mentioned professional UX designers: Apple iWork applications can only save to their native format. Every other supported format can only be exported to; this includes the file format of their previous version. Even opening of a file in a supported non-native format is treated like creation of a new file--on saving, the user is prompted to pick a name and a file in a native format is created. (Now I suppose you will tell me that Apple UX designers know nothing about users' needs...)
(In reply to comment #23) > Just out of curiosity: are there actual designers and UX experts working on > LO or is it just coders? This blindness to what's good for users (or lame > "code it yourself" replies) can hardly come from professional UX desginers. You seem to put an equality between "I want something" and "users need something". Just out of curiosity: Is derision and scorn your normal strategy when talking to someone who does not agree with you?
@David, dude stop feeding the trolls, just let it go as WONTFIX and move on! Maybe all this energy could be better spent doing something with support of the PDF ISO Standards...
I don't mean to be rude, but I don't think it will be productive to keep this discussion going on. I just asked a very simple question: are there UX designers working for LO or is it all just coders? I'd love to know who's in charge of UX and if there's any person responsible to discuss users needs who doesn't write a single line of code. I'm responsible for the needs of some 100 LO users (93 at this very moment in four different companies, but the number tends to grow) and I'd like to direct my questions to the right people. Again, no offense intended, but I don't think coders are the people who should handle users requests. I'll appreciate if anyone here can provide me with this information. Thanks.
@Aleve, *, (In reply to comment #27) >... I just asked a very simple question: are there UX > designers working for LO or is it all just coders? I'd love to know who's > in charge of UX and if there's any person responsible to discuss users > needs who doesn't write a single line of code. > > ...and I'd like to direct my questions to the right people. Again, no offense > intended, but I don't think coders are the people who should handle users > requests. Well, there is the Design team's wiki if you'd like to try there... https://wiki.documentfoundation.org/Design Stuart
OK. I'm leaving this vipers nest now. Will try to explain this suggestion to people with higher responsibilities in LibreOffice or eventually migrate to an application that respects their users and don't respond to suggestions with the absurdly agressive hostility I've experienced here. Not exactly a challenge, btw; it's unlikely ANY organization who cares about end users would treat people with the attitued shown here by recognized members of the "community". Shame on you. Bye.
@Aleve - do not open the bug again - you will be in violation of FDO policies and procedures: https://wiki.documentfoundation.org/QA/Bugzilla/Policies_and_Procedures David Tardon has been with the project for a long time. He has responded and changed that status to WONTFIX. No matter how many times you reopen it - it won't be fixed. Again - do not open the bug again.
I reopened the bug because it isn't solved and it deserves a fix. I just thought this was an open project where anyone could propose things without being harassed or nullified. Silly me, it seems there's a rigid bureaucracy in LibreOffice where only some privileged users dictate what happens to the project and fiercely attack proposals from end users or consultants. Enjoy working for yourselves guys. I'm moving all of my current and future customers to WPS Office. At least there you aren't fiercely attacked for suggesting reasonable features real end users can benefit from, but software programmers can't even understand. Who would have thought an office suite was created for software developers instead of office workers! 2014-08-08 17:06 GMT+02:00 <bugzilla-daemon@freedesktop.org>: > *Comment # 30 <https://bugs.freedesktop.org/show_bug.cgi?id=79811#c30> > on bug 79811 <https://bugs.freedesktop.org/show_bug.cgi?id=79811> from QA > Administrators <qa-admin@libreoffice.org> * > > @Aleve - do not open the bug again - you will be in violation of FDO policies > and procedures:https://wiki.documentfoundation.org/QA/Bugzilla/Policies_and_Procedures > > David Tardon has been with the project for a long time. He has responded and > changed that status to WONTFIX. No matter how many times you reopen it - it > won't be fixed. > > Again - do not open the bug again. > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > >
*** Bug 85209 has been marked as a duplicate of this bug. ***