sd: disable pdf import tests

Ashod Nakashian ashod.nakashian at collabora.co.uk
Tue Dec 17 14:29:00 UTC 2019


[++kendy]

On 12/17/19 2:18 AM, Stephan Bergmann wrote:
> On 17/12/2019 01:46, Ashod Nakashian wrote:
>> On 12/16/19 11:59 AM, Stephan Bergmann wrote:
>>> What's the reason for this change, and/or are there plans to enable 
>>> the tests again?  (`git log -SIMPORT_PDF_ELEMENTS` shows this to be 
>>> the only commit ever mentioning that identifier, so the tests are 
>>> indeed disabled since then.) 
>>
>> The tests are conditional on IMPORT_PDF_ELEMENTS because with the 
>> PDFium import logic, PDFs are imported as images, not individual 
>> elements (users can break the image into editable elements from the UI).
>>
>> Since these tests rely on importing PDF elements individually, the 
>> PDFium importing logic breaks them.
>
> But where does the the IMPORT_PDF_ELEMENTS macro get defined, if 
> anywhere?
>

Either that patch is missing, or I never got around to implementing it, 
since it would remain unused (i.e. no build would define it).

As I said, the idea here is to import PDFs as images using PDFium, which 
has a very high quality (and is much faster) than importing individual 
editable elements. So that's the "new" way of importing.

The user then breaks the image to editable elements (which is not 
perfect, but very close to the old way). This also removes the need to 
have out-of-process PDF parsing (due to license conflicts).

PDFium should overall be better, and where it isn't, we just need to 
improve it. As far as I can tell, the old importing logic gives us not 
much advantage.

So these tests aren't really useful anymore. They should be modified to 
do import+break and then check the results. But that isn't 
straight-forward and I ran out of time to do it.

Let me know if you have any concerns please.

Thanks.



More information about the LibreOffice mailing list