Issue 98564 - Move Hybrid-PDF-feature from PDF Import Extension into the OOo build
Summary: Move Hybrid-PDF-feature from PDF Import Extension into the OOo build
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 3.0
Hardware: Unknown All
: P3 Trivial with 2 votes (vote)
Target Milestone: ---
Assignee: Mathias_Bauer
QA Contact: issues@framework
: 99737 (view as issue list)
Depends on:
Reported: 2009-01-28 11:54 UTC by norbert2
Modified: 2010-05-17 20:27 UTC (History)
5 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description norbert2 2009-01-28 11:54:19 UTC
I don't understand why the Hybrid-PDF-feature is bound to the PDF Import Extension.

The only function of the extension should be to convert PDFs to Draw-Objects
which allows to import common PDFs.

The Hybrid-PDF-feature does not use such conversion functions since it only
opens an embedded ODF.

Further on support for Hybrid PDFs - if implemented usable - would be a very
useful and nearly unique feature that should work "out of the box".

So in my opinion from both, a technical and a usability point of view, there is
no sense to keep the Hybrid-PDF-feature bound to the PDF Import Extension.
Comment 1 Mathias_Bauer 2009-01-28 12:05:38 UTC
I would like to see a comment from the UX side (cc'ed fl). 
The main problem I see is that user's can't spot easily if a PDF is "normal" or
"hybrid" and they might get confused if they can open the latter in OOo but
can't open the former. 
As long as the editing of hybrid PDF is bound to the PDF import filter this
wouldn't happen.
Comment 2 gyll 2009-01-28 12:09:26 UTC
So now i guess i'll just have to cross my fingers and hope this one won't
receive the same treatment as , i.e. "duplicate of , Closing" and nothing
moves in this direction for another two years...
Comment 3 norbert2 2009-01-28 12:10:20 UTC
Confusion could be avoided by calling PDFs " Hybrid PDFs" and a
meaningful error message if the user tries to open a non-hybrid PDF.
Comment 4 norbert2 2009-01-28 12:11:09 UTC
... by calling PDFs " Hybrid PDFs"

... I mean in the file window
Comment 5 Mathias_Bauer 2009-01-28 12:18:21 UTC
@gyll: both issues have been closed for different reasons. One of them because
the extension was meant as the way to provide the desired enhancement and the
other because it had too much overlap with its duplicate. That's why I prefer to
have a unique issue for the particular question whether the hybrid PDF filter
should be part of the "real" PDF filter or not. 
Comment 6 gyll 2009-01-28 13:38:44 UTC
i started to write a whole essay about this HPDF thing, but i won't post it yet;
instead, i'll just come with an argument strictly related to the HPDF separation
from PDF import:

there is one very important reason for separating HPDF from the "plain" PDF
import functionality, no matter what course of integration the PDF import will
take in the future: *PDF format is not an OOo format*, changes are out of OOo
control, it's a cat and mouse thing to keep compatibility, import bugs will have
to be fixed all so often, etc, while *HPDF is fully under the control of OOo*,
thus effectively being a *native OOo format*

Does it make sense? Am i missing something essential?
Comment 7 Mathias_Bauer 2009-01-28 13:44:02 UTC
It's not wrong - technically spoken. But as OOo is an end user application we
must take the user's perspective to judge about features. And at least currently
I see a user experience problem if OOo can open only hybrid PDF but not the
others. The coupling between HPDF and PDF import avoids this.
Comment 8 gyll 2009-01-28 14:34:32 UTC
How about this:

All HPDF files have the extension ".ooo.pdf", and the OOo builds will only show
HPDF files in the Open dialog (not PDFs). Basially we say this: the .ooo.pdf
format is NOT the pdf format, but it's pdf-compatible.
Comment 9 norbert2 2009-01-28 14:55:06 UTC
@gyll: I like your idea. But I would prefer:
.odt.pdf (Writer)
.ods.pdf (Calc)

The question is if the Open dialogs (of all platforms) support filtering by such
multiple extensions.
Comment 10 norbert2 2009-01-28 14:57:59 UTC
This naming scheme would also indicate that there are two file types in one
file. I think this should annul mba's usability doubts.
Comment 11 thb 2009-01-28 20:10:44 UTC
Another option surely is to move "plain" pdf import into the core product as well. 

Just my 2 cents...
Comment 12 norbert2 2009-01-28 21:42:50 UTC
> Another option surely is to move "plain" pdf import into the core product as well.

@thb: But therefor we have to wait until the PDF Import Extension becomes
usable. .oO(if ever) Current 0.3.2 beta only disappoints users.
Comment 13 norbert2 2009-08-24 09:29:24 UTC
@mba: What about targeting this issue?
Comment 14 Mathias_Bauer 2009-08-26 10:39:02 UTC
Currently I'm still unsure whether this is a good idea at all. 
I will start a dicussions on the ux list as my attempt to include fl into our
discussion obviously failed.
Comment 15 Mathias_Bauer 2009-09-09 17:24:01 UTC
I tried to get some feedback und the ux list. It seems they don't have very
strong feelings about this issue. :-)

Anyway, I feel confirmed that the possible user experience problems are bigger
than the potential win.

So for me that's a "won't fix".
Comment 16 Mechtilde 2009-09-22 20:43:42 UTC
wontfix -> closed
Comment 17 Mathias_Bauer 2010-05-17 20:27:03 UTC
*** Issue 99737 has been marked as a duplicate of this issue. ***