You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Pe...@apache.org on 2026/09/07 23:21:16 UTC
New Pdf importer in construction
Hi all,
I am on a modernization for our pdf importer.
I would like to replace poppler becouse its gpl v2 and the license is
just difficult to digest for our code.
We have 2 other options where to move to.
1) Apache PDFBox, with the price of needing java. But our own project.
maybe we could have a collab there.
2) PDFium, with the price of beeing class b BSD license, but native
implementation.
I try our own food first. Then we still can decide to move on.
---
A second thing.
Import yes or no, we maintain an own pdfparser. It reads pdf, identifies
passwords encrypts and so on.
It is not the full import, just enough to identify and open the file in
a special case of hybrid pdf.
We could replace that code with qpdf. It would serve the same purpose,
same license. But less maintenace for us.
Is that something we should go for?
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: New Pdf importer in construction
Posted by "Pedro F. Giffuni via dev" <de...@openoffice.apache.org>.
Awesome!
FWIW, I wasted a bunch of AI tokens updating popplerand it was not worth it.
PDFium is somewhat more similar to poppler. You willhave to do your own checkout but at least you won'tneed to fiddle with autoconf :-).
Pedro.
On Monday, September 7, 2026 at 06:21:20 PM GMT-5, <pe...@apache.org> wrote:
Hi all,
I am on a modernization for our pdf importer.
I would like to replace poppler becouse its gpl v2 and the license is
just difficult to digest for our code.
We have 2 other options where to move to.
1) Apache PDFBox, with the price of needing java. But our own project.
maybe we could have a collab there.
2) PDFium, with the price of beeing class b BSD license, but native
implementation.
I try our own food first. Then we still can decide to move on.
---
A second thing.
Import yes or no, we maintain an own pdfparser. It reads pdf, identifies
passwords encrypts and so on.
It is not the full import, just enough to identify and open the file in
a special case of hybrid pdf.
We could replace that code with qpdf. It would serve the same purpose,
same license. But less maintenace for us.
Is that something we should go for?
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: New Pdf importer in construction
Posted by Dave Fisher <wa...@apache.org>.
> On Sep 7, 2026, at 5:49 PM, Petko@apache.org wrote:
>
>
> Am 08.09.2026 um 02:43 schrieb Dave Fisher:
>>
>>> On Sep 7, 2026, at 5:27 PM, Petko@apache.org wrote:
>>>
>>>
>>> Am 08.09.2026 um 02:20 schrieb Dave Fisher:
>>>>> On Sep 7, 2026, at 4:21 PM, Petko@apache.org wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I am on a modernization for our pdf importer.
>>>>>
>>>>> I would like to replace poppler becouse its gpl v2 and the license is just difficult to digest for our code.
>>>>>
>>>>> We have 2 other options where to move to.
>>>>>
>>>>> 1) Apache PDFBox, with the price of needing java. But our own project. maybe we could have a collab there.
>>>> I worked with PDFBox years ago. It is in general a lower level object level (COS) layer api. My team built a PDF to Powerpoint converter. It still runs, but I don’t have access to the code base. The lesson though is it is significant work to take PDF a print file format back into the component parts. We did the work over many years on the side.
>>> the conversion from PDF into components we have the code already and we can reuse it.
>>>>> 2) PDFium, with the price of beeing class b BSD license, but native implementation.
>>>> Being C++ this is likely a better fit.
>>> Can we simply use it? or is there some review process necessary?
>> I’m looking at https://pdfium.googlesource.com/pdfium/+/refs/heads/main/LICENSE and see ALv2. Where do you see BSD? And what number of clauses?
> https://github.com/documentcloud/pdfium/blob/master/LICENSE <https://github.com/documentcloud/pdfium/blob/master/LICENSE> says BSD 3-clause
This license is acceptable as it is category A - https://www.apache.org/legal/resolved.html#category-a
Best,
Dave
>>
>>
>>>>> I try our own food first. Then we still can decide to move on.
>>>>> ---
>>>>>
>>>>> A second thing.
>>>>>
>>>>> Import yes or no, we maintain an own pdfparser. It reads pdf, identifies passwords encrypts and so on.
>>>>>
>>>>> It is not the full import, just enough to identify and open the file in a special case of hybrid pdf.
>>>>>
>>>>> We could replace that code with qpdf. It would serve the same purpose, same license. But less maintenace for us.
>>>> From https://gpdf.dev
>>>>
>>>> gpdf is an open-source, MIT-licensed PDF generation library for Go
>>>>
>>>> That’s not a parser.
>>> I am proposing QPDF https://github.com/qpdf/qpdf
>>>>> Is that something we should go for?
>>>>>
>>>>>
>>>> Best of luck,
>>>> Dave
>>>>
>>>>> All the best
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org <ma...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org <ma...@openoffice.apache.org>
Re: New Pdf importer in construction
Posted by Pe...@apache.org.
Am 08.09.2026 um 02:43 schrieb Dave Fisher:
>
>> On Sep 7, 2026, at 5:27 PM, Petko@apache.org wrote:
>>
>>
>> Am 08.09.2026 um 02:20 schrieb Dave Fisher:
>>>> On Sep 7, 2026, at 4:21 PM, Petko@apache.org wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I am on a modernization for our pdf importer.
>>>>
>>>> I would like to replace poppler becouse its gpl v2 and the license is just difficult to digest for our code.
>>>>
>>>> We have 2 other options where to move to.
>>>>
>>>> 1) Apache PDFBox, with the price of needing java. But our own project. maybe we could have a collab there.
>>> I worked with PDFBox years ago. It is in general a lower level object level (COS) layer api. My team built a PDF to Powerpoint converter. It still runs, but I don’t have access to the code base. The lesson though is it is significant work to take PDF a print file format back into the component parts. We did the work over many years on the side.
>> the conversion from PDF into components we have the code already and we can reuse it.
>>>> 2) PDFium, with the price of beeing class b BSD license, but native implementation.
>>> Being C++ this is likely a better fit.
>> Can we simply use it? or is there some review process necessary?
> I’m looking at https://pdfium.googlesource.com/pdfium/+/refs/heads/main/LICENSE and see ALv2. Where do you see BSD? And what number of clauses?
https://github.com/documentcloud/pdfium/blob/master/LICENSE says BSD
3-clause
>
>
>>>> I try our own food first. Then we still can decide to move on.
>>>> ---
>>>>
>>>> A second thing.
>>>>
>>>> Import yes or no, we maintain an own pdfparser. It reads pdf, identifies passwords encrypts and so on.
>>>>
>>>> It is not the full import, just enough to identify and open the file in a special case of hybrid pdf.
>>>>
>>>> We could replace that code with qpdf. It would serve the same purpose, same license. But less maintenace for us.
>>> From https://gpdf.dev
>>>
>>> gpdf is an open-source, MIT-licensed PDF generation library for Go
>>>
>>> That’s not a parser.
>> I am proposing QPDF https://github.com/qpdf/qpdf
>>>> Is that something we should go for?
>>>>
>>>>
>>> Best of luck,
>>> Dave
>>>
>>>> All the best
>>>>
>>>> Peter
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: New Pdf importer in construction
Posted by Dave Fisher <wa...@apache.org>.
> On Sep 7, 2026, at 5:27 PM, Petko@apache.org wrote:
>
>
> Am 08.09.2026 um 02:20 schrieb Dave Fisher:
>>
>>> On Sep 7, 2026, at 4:21 PM, Petko@apache.org wrote:
>>>
>>> Hi all,
>>>
>>> I am on a modernization for our pdf importer.
>>>
>>> I would like to replace poppler becouse its gpl v2 and the license is just difficult to digest for our code.
>>>
>>> We have 2 other options where to move to.
>>>
>>> 1) Apache PDFBox, with the price of needing java. But our own project. maybe we could have a collab there.
>> I worked with PDFBox years ago. It is in general a lower level object level (COS) layer api. My team built a PDF to Powerpoint converter. It still runs, but I don’t have access to the code base. The lesson though is it is significant work to take PDF a print file format back into the component parts. We did the work over many years on the side.
> the conversion from PDF into components we have the code already and we can reuse it.
>>
>>> 2) PDFium, with the price of beeing class b BSD license, but native implementation.
>> Being C++ this is likely a better fit.
> Can we simply use it? or is there some review process necessary?
I’m looking at https://pdfium.googlesource.com/pdfium/+/refs/heads/main/LICENSE and see ALv2. Where do you see BSD? And what number of clauses?
>>
>>> I try our own food first. Then we still can decide to move on.
>>
>>> ---
>>>
>>> A second thing.
>>>
>>> Import yes or no, we maintain an own pdfparser. It reads pdf, identifies passwords encrypts and so on.
>>>
>>> It is not the full import, just enough to identify and open the file in a special case of hybrid pdf.
>>>
>>> We could replace that code with qpdf. It would serve the same purpose, same license. But less maintenace for us.
>> From https://gpdf.dev
>>
>> gpdf is an open-source, MIT-licensed PDF generation library for Go
>>
>> That’s not a parser.
> I am proposing QPDF https://github.com/qpdf/qpdf
>>
>>> Is that something we should go for?
>>>
>>>
>> Best of luck,
>> Dave
>>
>>> All the best
>>>
>>> Peter
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: New Pdf importer in construction
Posted by Pe...@apache.org.
Am 08.09.2026 um 02:20 schrieb Dave Fisher:
>
>> On Sep 7, 2026, at 4:21 PM, Petko@apache.org wrote:
>>
>> Hi all,
>>
>> I am on a modernization for our pdf importer.
>>
>> I would like to replace poppler becouse its gpl v2 and the license is just difficult to digest for our code.
>>
>> We have 2 other options where to move to.
>>
>> 1) Apache PDFBox, with the price of needing java. But our own project. maybe we could have a collab there.
> I worked with PDFBox years ago. It is in general a lower level object level (COS) layer api. My team built a PDF to Powerpoint converter. It still runs, but I don’t have access to the code base. The lesson though is it is significant work to take PDF a print file format back into the component parts. We did the work over many years on the side.
the conversion from PDF into components we have the code already and we
can reuse it.
>
>> 2) PDFium, with the price of beeing class b BSD license, but native implementation.
> Being C++ this is likely a better fit.
Can we simply use it? or is there some review process necessary?
>
>> I try our own food first. Then we still can decide to move on.
>
>> ---
>>
>> A second thing.
>>
>> Import yes or no, we maintain an own pdfparser. It reads pdf, identifies passwords encrypts and so on.
>>
>> It is not the full import, just enough to identify and open the file in a special case of hybrid pdf.
>>
>> We could replace that code with qpdf. It would serve the same purpose, same license. But less maintenace for us.
> From https://gpdf.dev
>
> gpdf is an open-source, MIT-licensed PDF generation library for Go
>
> That’s not a parser.
I am proposing QPDF https://github.com/qpdf/qpdf
>
>> Is that something we should go for?
>>
>>
> Best of luck,
> Dave
>
>> All the best
>>
>> Peter
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: New Pdf importer in construction
Posted by Dave Fisher <wa...@apache.org>.
> On Sep 7, 2026, at 4:21 PM, Petko@apache.org wrote:
>
> Hi all,
>
> I am on a modernization for our pdf importer.
>
> I would like to replace poppler becouse its gpl v2 and the license is just difficult to digest for our code.
>
> We have 2 other options where to move to.
>
> 1) Apache PDFBox, with the price of needing java. But our own project. maybe we could have a collab there.
I worked with PDFBox years ago. It is in general a lower level object level (COS) layer api. My team built a PDF to Powerpoint converter. It still runs, but I don’t have access to the code base. The lesson though is it is significant work to take PDF a print file format back into the component parts. We did the work over many years on the side.
> 2) PDFium, with the price of beeing class b BSD license, but native implementation.
Being C++ this is likely a better fit.
>
> I try our own food first. Then we still can decide to move on.
>
> ---
>
> A second thing.
>
> Import yes or no, we maintain an own pdfparser. It reads pdf, identifies passwords encrypts and so on.
>
> It is not the full import, just enough to identify and open the file in a special case of hybrid pdf.
>
> We could replace that code with qpdf. It would serve the same purpose, same license. But less maintenace for us.
From https://gpdf.dev
gpdf is an open-source, MIT-licensed PDF generation library for Go
That’s not a parser.
>
> Is that something we should go for?
>
>
Best of luck,
Dave
> All the best
>
> Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org