Re: [Podofo-users] PoDoFo virtual meeting

[Dominik Seichter via Podofo-users]

Looking forward to meeting many of you tomorrow!

Cheers,
 Dominik

On Tue, Jun 7, 2022 at 11:07 AM Francesco Pretto  wrote:

> Hello,
>
> as promised here is the link to conference room that will be used for
> the meeting tomorrow morning Wednesday June 8th at 10am (UTC+2).
>
> https://meet.google.com/ewa-whdr-wsp
>
> It's the same link for the ones that already received the invite. I
> will connect tomorrow at around 9:45 and start accepting other people
> at that time.
>
> Cheers,
> Francesco
>
>
> On Wed, 25 May 2022 at 23:20, Francesco Pretto  wrote:
> >
> > As corrected by Dominik, the meeting is set on June 8th at 10am UTC+2.
> > I just sent the invites to maintainers and contributors that showed
> > interest in the previous polls. The meeting room link will be shared
> > publicly a couple of days before the event takes place.
> >
> > Cheers,
> > Francesco
> >
>
>
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo virtual meeting

[Dominik Seichter via Podofo-users]

Sorry, Wednesday June 8th, 10am.

Dominik Seichter  schrieb am Mo., 23. Mai 2022,
14:23:

> Hi Francesco, Hi zxy, Hi Mabri, Hi PoDoFo developers,
>
> Francesco and I discussed it again and would like to hold the PoDoFo
> virtual meeting now on June 10th at 10am (UTC+2 Berlin/Rome/). Please
> block your calendars accordingly - invitation links will be sent soon. I
> would be happy if many of you could join and discuss the next steps.
> Please reserve 90 minutes for the meeting - we expect to stay in this time
> frame and do not need more of your precious time.
>
> The last planned agenda was:
> - [15min] Quick introductions, description of PoDoFo usage;
> - [10min] pdfmm improvements over PoDoFo, propose to merge back;
> - [25min] PoDoFo relicensing to more permissive license: yes/no, which one;
> - [25min] PoDoFo development model, responsibilities, git adoption.
>
> Kind regards,
>  Dominik
>
> On Tue, May 3, 2022 at 2:39 PM Francesco Pretto  wrote:
>
>> Hello guys,
>>
>> I'm sorry, I made a mistake in assuming that Dominik was available in
>> these weeks. I am not comfortable in holding this meeting without him,
>> so let's just delay it (I just deleted the doodle). Still I think it
>> was useful as we identified that Wednesday was preferred by most
>> people. I'm talking with Dominik right now: most probably we will
>> reschedule the event for Wednesday May 18th. I will update you soon.
>>
>> Cheers,
>> Francesco
>>
>>
>> On Tue, 3 May 2022 at 13:55, Dominik Seichter
>>  wrote:
>> >
>> > Hi all,
>> >
>> > Thanks for organizing this @Francesco Pretto !
>> > I am sorry to say that I cannot make it this week and/or the week
>> after. Sorry, for the short notice.
>> >
>> > Still, feel free to discuss next steps and do not hesitate to start the
>> meeting series without me.
>> >
>> > Best regards,
>> >  Dominik
>> >
>> > On Fri, Apr 29, 2022 at 10:24 AM Francesco Pretto 
>> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I remember everyone to answer to the Doodle:
>> >>
>> >>  https://doodle.com/meeting/participate/id/e5yK03qe
>> >>
>> >> So far the most voted day is next Wednesday, at 15.30 CEST. I think at
>> >> this point that probably the event will be held within strict workdays
>> >> (Mon-Thu, better exclude Friday). Since some people may want to join
>> >> but prefer evenings, including one person that did patch reviews and
>> >> may hold some stakes, I added another option on Wednesday May 11th,
>> >> 17.30-19.00 CEST. I guess we all have a job, and that would basically
>> >> be a late call of the day, possibly prolonging the work day a bit, and
>> >> also people that can't have calls regarding PoDoFo during their job
>> >> could at least get a (small) leave to finish job earlier that day and
>> >> be able to join the meeting. I ask people that voted so far to also
>> >> express availability/unavailability for that day, and add some more
>> >> availabilities. I remind you that the scope of these doodles is to try
>> >> to maximize participation and that there is also the yellow "if need
>> >> be" option where you can state an availability that is not comfortable
>> >> for you but still feasible.
>> >>
>> >> Thank you again!
>> >>
>> >> Cheers,
>> >> Francesco
>> >>
>> >>
>> >> On Mon, 25 Apr 2022 at 13:56, Francesco Pretto 
>> wrote:
>> >> >
>> >> > Hello PoDoFo maintainers/devs,
>> >> >
>> >> > I got some replies to the meeting poll and decided to create a
>> doodle based on the results, which I attached. Looking at results, there's
>> seems to be a preference on attending during working days/hours, so I put
>> most options on those time slots, with a couple exceptions (late Friday 6th
>> and morning Saturday 7th).
>> >> >
>> >> > https://doodle.com/meeting/participate/id/e5yK03qe
>> >> >
>> >> > What I would like to discuss, with a tentative schedule:
>> >> > - [15min] Quick introductions, description of PoDoFo usage;
>> >> > - [10min] pdfmm improvements over PoDoFo, propose to merge back;
>> >> > - [25min] PoDoFo relicensing to more permissive license: yes/no,
>> which one;
>> >> > - [25min] PoDoFo development model, responsibilities, git adoption.
>> >> >
>> >> > Suggestions are welcome, but for such schedule I believe 1h and 15
>> min is the bare minimum, and there may be no time to take decisions or
>> discuss many topics. We'll see, but please be open to stay few more minutes
>> more. Also on late Friday and Saturday morning there may be more time to
>> discuss topics more in depth, hence I created longer meeting slots in those
>> days. About which conference room to use: there's seems to be a slightly
>> preference of using Google Meet, which the second runner Microsoft Teams.
>> Google Meet works well without any application, so I think we should use
>> that this time, with possibility to switch to Discord for quick chats/talks.
>> >> >
>> >> > Please, fill the doodle as well and thank you very much for your
>> participation!
>> >> >
>> >> > Cheers,
>> >> > Francesco
>> >> >
>> >> > On 

Re: [Podofo-users] PoDoFo virtual meeting

[Dominik Seichter via Podofo-users]

Hi Francesco, Hi zxy, Hi Mabri, Hi PoDoFo developers,

Francesco and I discussed it again and would like to hold the PoDoFo
virtual meeting now on June 10th at 10am (UTC+2 Berlin/Rome/). Please
block your calendars accordingly - invitation links will be sent soon. I
would be happy if many of you could join and discuss the next steps.
Please reserve 90 minutes for the meeting - we expect to stay in this time
frame and do not need more of your precious time.

The last planned agenda was:
- [15min] Quick introductions, description of PoDoFo usage;
- [10min] pdfmm improvements over PoDoFo, propose to merge back;
- [25min] PoDoFo relicensing to more permissive license: yes/no, which one;
- [25min] PoDoFo development model, responsibilities, git adoption.

Kind regards,
 Dominik

On Tue, May 3, 2022 at 2:39 PM Francesco Pretto  wrote:

> Hello guys,
>
> I'm sorry, I made a mistake in assuming that Dominik was available in
> these weeks. I am not comfortable in holding this meeting without him,
> so let's just delay it (I just deleted the doodle). Still I think it
> was useful as we identified that Wednesday was preferred by most
> people. I'm talking with Dominik right now: most probably we will
> reschedule the event for Wednesday May 18th. I will update you soon.
>
> Cheers,
> Francesco
>
>
> On Tue, 3 May 2022 at 13:55, Dominik Seichter
>  wrote:
> >
> > Hi all,
> >
> > Thanks for organizing this @Francesco Pretto !
> > I am sorry to say that I cannot make it this week and/or the week after.
> Sorry, for the short notice.
> >
> > Still, feel free to discuss next steps and do not hesitate to start the
> meeting series without me.
> >
> > Best regards,
> >  Dominik
> >
> > On Fri, Apr 29, 2022 at 10:24 AM Francesco Pretto 
> wrote:
> >>
> >> Hello,
> >>
> >> I remember everyone to answer to the Doodle:
> >>
> >>  https://doodle.com/meeting/participate/id/e5yK03qe
> >>
> >> So far the most voted day is next Wednesday, at 15.30 CEST. I think at
> >> this point that probably the event will be held within strict workdays
> >> (Mon-Thu, better exclude Friday). Since some people may want to join
> >> but prefer evenings, including one person that did patch reviews and
> >> may hold some stakes, I added another option on Wednesday May 11th,
> >> 17.30-19.00 CEST. I guess we all have a job, and that would basically
> >> be a late call of the day, possibly prolonging the work day a bit, and
> >> also people that can't have calls regarding PoDoFo during their job
> >> could at least get a (small) leave to finish job earlier that day and
> >> be able to join the meeting. I ask people that voted so far to also
> >> express availability/unavailability for that day, and add some more
> >> availabilities. I remind you that the scope of these doodles is to try
> >> to maximize participation and that there is also the yellow "if need
> >> be" option where you can state an availability that is not comfortable
> >> for you but still feasible.
> >>
> >> Thank you again!
> >>
> >> Cheers,
> >> Francesco
> >>
> >>
> >> On Mon, 25 Apr 2022 at 13:56, Francesco Pretto 
> wrote:
> >> >
> >> > Hello PoDoFo maintainers/devs,
> >> >
> >> > I got some replies to the meeting poll and decided to create a doodle
> based on the results, which I attached. Looking at results, there's seems
> to be a preference on attending during working days/hours, so I put most
> options on those time slots, with a couple exceptions (late Friday 6th and
> morning Saturday 7th).
> >> >
> >> > https://doodle.com/meeting/participate/id/e5yK03qe
> >> >
> >> > What I would like to discuss, with a tentative schedule:
> >> > - [15min] Quick introductions, description of PoDoFo usage;
> >> > - [10min] pdfmm improvements over PoDoFo, propose to merge back;
> >> > - [25min] PoDoFo relicensing to more permissive license: yes/no,
> which one;
> >> > - [25min] PoDoFo development model, responsibilities, git adoption.
> >> >
> >> > Suggestions are welcome, but for such schedule I believe 1h and 15
> min is the bare minimum, and there may be no time to take decisions or
> discuss many topics. We'll see, but please be open to stay few more minutes
> more. Also on late Friday and Saturday morning there may be more time to
> discuss topics more in depth, hence I created longer meeting slots in those
> days. About which conference room to use: there's seems to be a slightly
> preference of using Google Meet, which the second runner Microsoft Teams.
> Google Meet works well without any application, so I think we should use
> that this time, with possibility to switch to Discord for quick chats/talks.
> >> >
> >> > Please, fill the doodle as well and thank you very much for your
> participation!
> >> >
> >> > Cheers,
> >> > Francesco
> >> >
> >> > On Tue, 12 Apr 2022 at 20:55, Francesco Pretto 
> wrote:
> >> >>
> >> >> Hello PoDoFo devs,
> >> >>
> >> >> last Sunday I wrote in another thread about an attempt to organize a
> >> >> PoDoFo virtual meeting. While Dominik 

[Podofo-users] Announcing PoDoFo Release 0.9.8

[Dominik Seichter via Podofo-users]

Hi everyone,

The PoDoFo developers are happy to announce the release of PoDoFo 0.9.8.
This release contains over 25 patches submitted by various contributors
(see SVN Log for details:
https://sourceforge.net/p/podofo/code/commit_browser). We encourage all
users to upgrade to this release.

Tarball has been uploaded to:
https://sourceforge.net/projects/podofo/files/podofo/0.9.8/

Also, this will be the final release of PoDoFo based on the current
codebase. After the release we plan to introduce two major changes to
PoDoFo development.

First of all, we will lock/close the current SVN trunk and switch PoDoFo
development to a more modern development platform (
https://github.com/podofo/podofo), where we can leverage state of the art
development features such as Continuous Integration or Pull Requests. The
mailing list and webpage will stay on SourceForge as well as the issue
tracker. Still, we will open a new issue tracker for the new development
environment and gradually migrate open issues. We will share more news on
this, once the new development environment was set up.

*Please do not use SVN anymore from now on. Any new development should go
GitHub. Please let me know if you need access.*

Secondly and most importantly, we will replace the current codebase of
PoDoFo with the amazing work Francesco Pretto has done with pdfmm (
https://github.com/pdfmm/pdfmm). pdfmm is based on PoDoFo but with an
improved and reworked API based on C++17 which we consider more suitable
for future development of PoDoFo. After rebasing PoDoFo on pdfmm, we plan
to release PoDoFo 1.0.0.

Please note, PoDoFo 1.0.0 will be API incompatible (binary and in source
code) with PoDoFo 0.9.8. We expect migration steps to be necessary. PoDoFo
Tools are currently being ported to pdfmm as a showcase for the migration.

Best regards,
 Dominik
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo Release / Outstanding Patches

[Dominik Seichter via Podofo-users]

Hi,

As there hasn't been any updates. I would suggest to package the release
this week and after that switch over to Git.
If necessary, we can still create a branch from Git (also in parallel after
the pdfmm merge back).

Best regards,
 Dominik

On Mon, Apr 25, 2022 at 8:46 AM Dominik Seichter 
wrote:

> Hi Mabri and developers,
>
> Just wanted to check if anybody plans to deliver any patches to PoDoFo SVN
> or if it would be a good time to package up the release.
> @Matthew Brincke  : You mentioned you have something
> in the pipeline.
>
> As zyx has suggested, we should otherwise define a deadline. For me
> possible release dates could be this or next week or then only at the end
> of may.
>
> Best regards,
>  Dominik
>
> Especially @Dominik: IIRC (I've lurked here in the meantime and looked in
>> the issue tracker on SourceForge a few times),
>> there are some patches still outstanding which I'd like to test (using
>> some "poor man's CI/test automation" locally most likely)
>> and then apply to SVN trunk, which fix security issues/crashers, so that
>> I'd be grateful for considering them
>> necessary for the next release. I'm not currently doing other work (a day
>> job), so I think I can do this quickly,
>> I hope starting tomorrow (Sunday). For the other issues labeled
>> "security" I'd also like to see what I can do
>> (I hope to produce patches and then handle them like the others, could
>> you please do too?).
>>
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo virtual meeting

[Dominik Seichter via Podofo-users]

Hi all,

Thanks for organizing this @Francesco Pretto  !
I am sorry to say that I cannot make it this week and/or the week after.
Sorry, for the short notice.

Still, feel free to discuss next steps and do not hesitate to start the
meeting series without me.

Best regards,
 Dominik

On Fri, Apr 29, 2022 at 10:24 AM Francesco Pretto  wrote:

> Hello,
>
> I remember everyone to answer to the Doodle:
>
>  https://doodle.com/meeting/participate/id/e5yK03qe
>
> So far the most voted day is next Wednesday, at 15.30 CEST. I think at
> this point that probably the event will be held within strict workdays
> (Mon-Thu, better exclude Friday). Since some people may want to join
> but prefer evenings, including one person that did patch reviews and
> may hold some stakes, I added another option on Wednesday May 11th,
> 17.30-19.00 CEST. I guess we all have a job, and that would basically
> be a late call of the day, possibly prolonging the work day a bit, and
> also people that can't have calls regarding PoDoFo during their job
> could at least get a (small) leave to finish job earlier that day and
> be able to join the meeting. I ask people that voted so far to also
> express availability/unavailability for that day, and add some more
> availabilities. I remind you that the scope of these doodles is to try
> to maximize participation and that there is also the yellow "if need
> be" option where you can state an availability that is not comfortable
> for you but still feasible.
>
> Thank you again!
>
> Cheers,
> Francesco
>
>
> On Mon, 25 Apr 2022 at 13:56, Francesco Pretto  wrote:
> >
> > Hello PoDoFo maintainers/devs,
> >
> > I got some replies to the meeting poll and decided to create a doodle
> based on the results, which I attached. Looking at results, there's seems
> to be a preference on attending during working days/hours, so I put most
> options on those time slots, with a couple exceptions (late Friday 6th and
> morning Saturday 7th).
> >
> > https://doodle.com/meeting/participate/id/e5yK03qe
> >
> > What I would like to discuss, with a tentative schedule:
> > - [15min] Quick introductions, description of PoDoFo usage;
> > - [10min] pdfmm improvements over PoDoFo, propose to merge back;
> > - [25min] PoDoFo relicensing to more permissive license: yes/no, which
> one;
> > - [25min] PoDoFo development model, responsibilities, git adoption.
> >
> > Suggestions are welcome, but for such schedule I believe 1h and 15 min
> is the bare minimum, and there may be no time to take decisions or discuss
> many topics. We'll see, but please be open to stay few more minutes more.
> Also on late Friday and Saturday morning there may be more time to discuss
> topics more in depth, hence I created longer meeting slots in those days.
> About which conference room to use: there's seems to be a slightly
> preference of using Google Meet, which the second runner Microsoft Teams.
> Google Meet works well without any application, so I think we should use
> that this time, with possibility to switch to Discord for quick chats/talks.
> >
> > Please, fill the doodle as well and thank you very much for your
> participation!
> >
> > Cheers,
> > Francesco
> >
> > On Tue, 12 Apr 2022 at 20:55, Francesco Pretto  wrote:
> >>
> >> Hello PoDoFo devs,
> >>
> >> last Sunday I wrote in another thread about an attempt to organize a
> >> PoDoFo virtual meeting. While Dominik told me such events were never
> >> organized nor needed to aid PoDoFo development, I think having one in
> >> this phase may help to revive interest in PoDoFo and be a very good
> >> opportunity to meet each other. I already had the chance to talk with
> >> Dominik face to face last week and it was very useful and interesting
> >> to me: enlarge the meeting to previous and current maintainers, patch
> >> contributors and all people interested in PoDoFo development would be
> >> a good step in improving understanding who is using PoDoFo (and for
> >> what) and would certainly aid future steps being taken, other than
> >> helping to renovate a sense of community. Of course you already know I
> >> have several purposes about development PoDoFo, which possibly I would
> >> like to present and discuss. It's clear that PoDoFo has a small user
> >> base/community behind, but I still invite you to fill the form I
> >> created and state your interest/preferences:
> >>
> >>
> https://docs.google.com/forms/d/e/1FAIpQLSdAQrk_ktmgzJI_eZvevfvAlfG5EsttVftouNO3cfUKT2uUig/viewform?usp=sf_link
> >>
> >> Depending on the responses on this I will then prepare a doodle to try
> >> set a meeting date. Also I remind you I created an experimental
> >> #PoDoFo discord channel:
> >>
> >> https://discord.gg/SAVm4DVN
> >>
> >> Thank you for your support in this initiative!
> >>
> >> Cheers,
> >> Francesco
>
>
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>

[Podofo-users] PoDoFo Release / Outstanding Patches

[Dominik Seichter via Podofo-users]

Hi Mabri and developers,

Just wanted to check if anybody plans to deliver any patches to PoDoFo SVN
or if it would be a good time to package up the release.
@Matthew Brincke  : You mentioned you have something in
the pipeline.

As zyx has suggested, we should otherwise define a deadline. For me
possible release dates could be this or next week or then only at the end
of may.

Best regards,
 Dominik

Especially @Dominik: IIRC (I've lurked here in the meantime and looked in
> the issue tracker on SourceForge a few times),
> there are some patches still outstanding which I'd like to test (using
> some "poor man's CI/test automation" locally most likely)
> and then apply to SVN trunk, which fix security issues/crashers, so that
> I'd be grateful for considering them
> necessary for the next release. I'm not currently doing other work (a day
> job), so I think I can do this quickly,
> I hope starting tomorrow (Sunday). For the other issues labeled "security"
> I'd also like to see what I can do
> (I hope to produce patches and then handle them like the others, could you
> please do too?).
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Proposal for release announcement

[Dominik Seichter via Podofo-users]

Hi folks!

I would like to share a draft of the release announcement for PoDoFo 0.9.8.
I would like to package and publish this release as soon as mabri gives me
a "go" once he is done with the patches on his list.

Feel free to share your feedback.

*Announcing PoDoFo release 0.9.8*

The PoDoFo developers are happy to announce the release of PoDoFo 0.9.8.
This release contains over 25 patches submitted by various contributors
(see SVN Log for details:
https://sourceforge.net/p/podofo/code/commit_browser). We encourage all
users to upgrade to this release.

Also, this will be the final release of PoDoFo based on the current
codebase. After the release we plan to introduce two major changes to
PoDoFo development.

First of all, we will lock/close the current SVN trunk and switch PoDoFo
development to a more modern development platform (e.g. GitHub), where we
can leverage state of the art development features such as Continuous
Integration or Pull Requests. The mailing list and webpage will stay on
SourceForge as well as the issue tracker. Still, we will open a new issue
tracker for the new development environment and gradually migrate open
issues. We will share more news on this, once the new development
environment was set up.

Secondly and most importantly, we will replace the current codebase of
PoDoFo with the amazing work Francesco Pretto has done with pdfmm (
https://github.com/pdfmm/pdfmm). pdfmm is based on PoDoFo but with an
improved and reworked API based on C++17 which we consider more suitable
for future development of PoDoFo. After rebasing PoDoFo on pdfmm, we plan
to release PoDoFo 1.0.0.

Please note, PoDoFo 1.0.0 will be API incompatible (binary and in source
code) with PoDoFo 0.9.8. We expect migration steps to be necessary. PoDoFo
Tools are currently being ported to pdfmm as a showcase for the migration.

Best regard,
 Dominik
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] PoDoFo on GitHub

[Dominik Seichter via Podofo-users]

Hi PoDoFo developers,

I have setup a new organization on GitHub and created an empty repository
for PoDoFo:

https://github.com/podofo/podofo

I hope this is fine for everybody and we can use this for further
development post 0.9.8 release.
If you want to be added to the project, please drop me a private mail with
your GitHub credentials.

@Francesco Pretto  : I have seen you have setup a few
actions for the pdfmm GitHub project: https://github.com/pdfmm/pdfmm/actions
Can we reuse them in the future on the podofo project as a starting point
for CI?

Kind regards,
 Dominik
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo virtual meeting

[Dominik Seichter via Podofo-users]

Hi everyone!

Thanks for setting this up, @Francesco Pretto  !

Let's stay in touch on discord and looking forward to be seeing you in a
virtual meeting!

Regards,
 Dominik



On Tue, Apr 12, 2022 at 8:56 PM Francesco Pretto  wrote:

> Hello PoDoFo devs,
>
> last Sunday I wrote in another thread about an attempt to organize a
> PoDoFo virtual meeting. While Dominik told me such events were never
> organized nor needed to aid PoDoFo development, I think having one in
> this phase may help to revive interest in PoDoFo and be a very good
> opportunity to meet each other. I already had the chance to talk with
> Dominik face to face last week and it was very useful and interesting
> to me: enlarge the meeting to previous and current maintainers, patch
> contributors and all people interested in PoDoFo development would be
> a good step in improving understanding who is using PoDoFo (and for
> what) and would certainly aid future steps being taken, other than
> helping to renovate a sense of community. Of course you already know I
> have several purposes about development PoDoFo, which possibly I would
> like to present and discuss. It's clear that PoDoFo has a small user
> base/community behind, but I still invite you to fill the form I
> created and state your interest/preferences:
>
>
> https://docs.google.com/forms/d/e/1FAIpQLSdAQrk_ktmgzJI_eZvevfvAlfG5EsttVftouNO3cfUKT2uUig/viewform?usp=sf_link
>
> Depending on the responses on this I will then prepare a doodle to try
> set a meeting date. Also I remind you I created an experimental
> #PoDoFo discord channel:
>
> https://discord.gg/SAVm4DVN
>
> Thank you for your support in this initiative!
>
> Cheers,
> Francesco
>
>
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo & PDF Linearalization

[Dominik Seichter via Podofo-users]

Hi all,

Just came across this older thread and just wanted to give my 2cents on it.

First of all, Francesco's observation is correct IMHO: My conclusion is
that PoDoFo linearization support overall (read an write) has always been
quite incomplete at best, and quite certainly broken/buggy enough to be
disabled quite early in PoDoFo development, so that nothing is working
about PDF linearization now.

I think it was a good decision to remove this code in pdfmm as it is not
working and having an API that is not working is just misleading. I would
agree to have this code removed in PoDoFo as well, as I do not think it is
possible to fix it in the current state. If someone would want to
reintroduce PDF linearization for writing, a complete reengineering would
be required.

Best regards,
 Dominik


On Fri, Feb 18, 2022 at 9:25 AM Francesco Pretto  wrote:

> Hello Connor,
>
> I'm the maintainer of pdfmm, a PoDoFo fork, but I had to evaluate what
> was done in PoDoFo about PDF linearization. I will try to answer you
> in a fair way, to the best of my knowledge. First, let's clarify what
> main capabilities PDF Linearization should enable, among others.
> According to Annex F of PDF 32000-1:2008 the PDF linearization, :
> - allows to "display the first page as quickly as possible" (not
> necessarily the page 0);
> - when the user requests another page of an open document it allows to
> "display that page as quickly as possible".
>
> PDF linearization as described by Annex F is implemented by
> encapsulating the content of the first page document in a "Incremental
> Update" like serialization that must be at the beginning of the
> document, together with a "linearization dictionary" that should be
> the first object of the document. The rest of the document is appended
> after this fake "incremental update" and "the pages shall be
> contiguous and shall be ordered by page number", and "the objects
> required to display that page shall be grouped together" and "the
> order of objects referenced from the page object should facilitate
> [...] incremental display of the page data as it arrives".
>
> Let's distinguish between PDF linearization read support, intended as
> the ability to exploit the organization of a linearized PDF document
> and write support as the ability to create a compliant linearized PDF.
> PoDoFo attempted to have linearization read support but it was
> disabled in 2009[1]. Also just reading the document structure (and not
> the object content) is performing a lot of of seeks that would kill
> the purpose of linearization (I actually removed those seeks in
> pdfmm).
>
>  About PDF linearization write support, which I think you are most
> interested in, PoDoFo appears to do some work related to linearization
> in PdfVecObjects class[2], but in all the work related to create the
> linearization dictionary was disabled in PdfWriter[3] even earilier in
> 2007. Also there's no sign of the needed fake incremental update that
> contains the content of the first page.
>
> My conclusion is that PoDoFo linearization support overall (read an
> write) has always been quite incomplete at best, and quite certainly
> broken/buggy enough to be disabled quite early in PoDoFo development,
> so that nothing is working about PDF linearization now, and the
> leftover API that seems to enable linearization is just code that got
> rotten (that's why I decided to remove it completely in pdfmm). If one
> decided to work on revamping the PDF linearization support I would
> recommend to read the specification and start it from scratch, not
> basing on the left-over code in PoDoFo, but it's a weeks/months long
> full time work. Of course I would love to re-introduce it in pdfmm,
> where the situation is just much more clean than in PoDoFO, but
> unfortunately that work is not in my top priorities.
>
> I hope I was factually correct about the current state of PoDoFO.
> Other people may add further details or correct me if I was wrong.
>
> Regards,
> Francesco
>
> [1]
> https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/trunk/src/podofo/base/PdfParser.cpp#l300
> [2]
> https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/trunk/src/podofo/base/PdfVecObjects.cpp#l308
> [3]
> https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/trunk/src/podofo/base/PdfWriter.cpp#l274
>
>
> On Thu, 17 Feb 2022 at 23:00, Connor Black  wrote:
> >
> > Hey,
> >
> >
> >
> > I am currently evaluating this library for use in a commercial product
> and I was curious what linearalization would look like using PoDoFo. I have
> spent the last couple of days looking through documentation and trying to
> look into how it would work but the most I can grasp is that PdfWriter has
> the option to set linearalization through SetLineralization – but I have
> not been able to find any examples or successfully use the PdfWriter class
> to produce these results. I was wondering if you could provide a little
> code snippet showing how PdfWriter would be used 

Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo

[Dominik Seichter via Podofo-users]

Hi Zyx, Hi Francesco,

I also wanted to continue this discussion. Sorry again for the long delay.
If you prefer, we could also have a phone/video chat about these points
(also whoever is interested could join in).

>From my point of view, the most important points/next steps are as follows
(feel free to correct me if I am wrong):

1) Decision on splitting PoDoFo and PoDoFo Tools:
I would prefer to keep them in the same repository to make sure they are in
a buildable state all the time and can also be used as examples for working
with PoDoFo.
@Francesco Pretto  : It would be great if you could take
the additional effort and port them to pdfmm. The diff could also be a nice
migration guideline for the future.

2) Decision on license of PoDoFo Tools:
PoDoFo Tools are currently GPL whereas the library itself is LGPL. This
e.g. makes it hard to copy from tools to the library. From my point of
view, we should align the license so that the tools have the same license
as the library (currently LGPL, for the future see separate discussion).

3) Merging back pdfmm in podofo / replacing podofo with pdfmm:
I would agree to the proposal from Francesco here. We should do one last
release of PoDoFo 0.9.8 based on the current svn trunk and then replace it.
@Zyx: When would be a good point of time for this? Can I just bundle a
trunk, do quick tests and upload it? I am not sure about the current state.

4) Move to Git:
Yes, let's move to Git* and keep website, mailing list on sourceforge.

5) relicensing to MPL:
I am in general open to that, but let's keep discussion in separate mail
thread.


Best regards,
 Dominik




On Tue, Feb 22, 2022 at 9:39 AM zyx  wrote:

> On Mon, 2022-02-21 at 12:17 +0100, Francesco Pretto wrote:
> > Please understand that after the port I would still need to "recruit"
> > people to ensure they actually work as intended. In short words: they
> > need a maintainer who cares about them.
>
> Hi,
> sure, that's fine. As far as I can tell, it's no change from the
> current state.
> Bye,
> zyx
>
>
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo

[Dominik Seichter via Podofo-users]

Hi Francesco,

First of all, congratulations on the release and thanks for all the
information.
I will go through your notes and also other mails, but wanted to give you
some feedback at first.

Kind regards,
 Dominik

On Sat, Feb 12, 2022 at 7:16 PM Francesco Pretto  wrote:

> Hello Dominik, PoDoFo maintainers, contributors and users,
>
> I'm happy to announce that after other months of strong development
> pdfmm, the PoDoFo fork I talked about last year, reached its first tagged
> release 0.9.20. The big list of changes[1] is comprensive of the changes
> of the first announce[2] together with latest features that I will
> summarize
> below:
>
> - A new PdfDynamicEncoding class has been added and set as the default
> encoding in font creation. The dynamic encoding is a CID encoding that
> gets built automatically when encoding strings. That is: Unicode
> characters are automatically mapped to arbitrary CID characters and a
> valid /ToUnicode map is created in the font when embedding. This mean
> you can just do painter.DrawText("Unicode string АБВГДЕЁ", x, y) and
> forget about picking or building a right PdfEncoding for the font.
> Beware: this doesn't yet mean full text shaping/ligatures support, but
> it's a big step in the right direction for supporting more complex scripts,
> such as arabic and asian ones;
> - Standard14 fonts coming from PDFium[3] (PDFium is a recent pdf
> renderer developed by google) have been bundled, enabling full font
> embedding of such fonts;
> - A new PdfContentsReader class has been added: this class completely
> replaces the old PdfContentsTokenizer (which was removed), providing
> Pdf operators recognition and XObject following. This class is going
> to be the core tool in building a PDF renderer and other PDF processing
> operations;
> - C++ move semantics has been added to most core classes
> (PdfVariant/PdfObject/PdfArray/PdfDictionary), allowing to improve
> performance in parsing indirect objects and page contents. I don't
> have measurements but this effectively halved the timings of my test
> suites. A lot other of micro optimizations appear to be possible following
> this move;
> - PDF/A preservation: the original PoDoFo library is not able to
> manipulate a PDF/A compliant file without loosing this compliance.
> pdfmm is now able to perform saves/incremental saves preserving the
> compliance (that is: updating the XMP metadata and respecting some
> serialization restrictions of PDF/A);
> - The automatic unit tests have been restored and a full-fledged
> continuous integration for Windows, linux and mac has been implemented
> using on github actions[4];
> - A playground area with full set of static dependencies built for
> Win64, macos-x86_64, linux-x86_64 has been prepared[5]. While the
> dependencies will comes without warranty, this makes testing/developing
> pdfmm completely hustle-free;
> - A lot of bug fixes and other things that I forget about, just look the
> changelog and git commit descriptions.
>
> While I still somehow don't recommend anyone to use pdfmm until I
> settle the API review (something that I plan to do together with other
> tasks
> before this summer in a 0.10.x release[6]) and assuming the C++ PDF
> manipulation user base to be quite small, I begin to think that pdfmm
> won't be ignored for much longer. pdfmm is at least 1 man year worth of
> work ahead of PoDoFo and represents a solid improvement in features
> and API quality, with a very little set of features dropped (only the
> broken
> PDF linearization support has been removed and Type1 font subsetting
> is temporarily disabled) and while I noticed a couple of interesting
> PoDoFo 0.9.x patches emerging (stack guards and modern encryption
> protocols) I doubt anyone at this point is really doing the same kind
> of active development I am pushing into pdfmm (or at least nobody talk
> about it openly in the PoDoFo mailing list). I thought a lot about my
> relationship with the PoDoFo project in these months and while I like to
> work without constraints and still aim to push for my vision of what
> a modern C++ PDF manipulation should be, I am concerned that this
> work may not settle in the long run. Convinced by zyx's openings in a
> recent discussion[7] I offer the community to merge back this work to
> PoDoFo. I am going to do this work at some conditions, which should be
> seen more as a concrete plan of action:
>
> 1) PoDoFo project should be split in two different subprojects,
> one covering the library and unit tests, one covering the tools.
> I will initially maintain the new library and test code, and keep this
> role until the I feel a good fit for the role and the community is
> comfortable with my work. Other people should take a step forward and
> show interest in porting the PoDoFo tools, which I will not maintain
> as a whole (I can port/maintain one or two). The old PoDoFo 0.9.x
> codeline will be branched and maintained separately by current people;
> 2) pdfmm should 

Re: [Podofo-users] Few improvements for podofoimpose

[Dominik Seichter via Podofo-users]

Hi Chris,

Thank you very much for your valuable contribution. I committed all four
patches to SVN.

Kindest regards,
Dominik


On Fri, Jan 22, 2021 at 5:56 PM  wrote:

> Hi,
>
> Thanks for such a great tool (PoDoFo in general).
>
> I made a few improvements to the podofoimpose tool. Hope they are useful
> to others as well. Here a short explanation for each patch.
>
> - 1_Allow_to_set_the_bounding_box_with_the_legacy_plan_reader.patch
> Also allow to set the bounding box with the legacy plan reader.
>
> - 2_Return_none_zero_return_code.patch
> If an exception happens, return none zero return code.
>
> - 3_Allow_scaling_of_inserted_pages.patch
> This is the biggest change. With this change it is possible to scale an
> inserted page (one by one with different scaling). I tried to make sure,
> that all additional parameters are optional and the previous behavior is
> retained if no scaling factors are given.
>
> - 4_Handle_Name_datatype_correctly.patch
> Handle the Name datatype correctly. Without this fix the Name datatype
> got converted to a dictionary after imposing the PDF. This resulted in
> having an invalid /ColorSpace for images and thus images that did not
> show up in the resulting PDF.
>
> I tested and applied all patches against the trunk.
>
> Best regards,
> Chris
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] PoDoFo and PoDoFoBrowser 0.9.7 release tarballs available

[Dominik Seichter via Podofo-users]

Hi all,

I have uploaded release tarballs for podofo and podofobrowser 0.9.7 and
have created the required release tags.

Thanks for all the contributions.

http://podofo.sourceforge.net/

Best regards,
Dominik
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PdfDate does not comply to pdf standard

[Dominik Seichter via Podofo-users]

Hi Federico,

Thanks for the explanation. It has been apparently a long time since I
worked on the internal details of PdfDate. In my opinion, comparing to
time_t(-1) makes sense for invalid dates.
I will update the test accordingly.

Best regards,
 Dominik

On Sat, Jan 9, 2021 at 12:56 AM Federico Kircheis <
federico.kirch...@gmail.com> wrote:

> On 07/01/2021 11.15, Dominik Seichter wrote:
> > Hi Federico,
> >
> > Updated set of patches is pushed with an additional test.
> >
> > One weird issue:
> >
> > void DateTest::testParseDateInvalid()
> > {
> >  PdfString tmp("D:2012020");
> >  PdfDate date(tmp);
> >
> >  struct tm  _tm;
> >  memset (&_tm, 0, sizeof(struct tm));
> >
> >  const time_t t = date.GetTime();
> >  localtime_r(, &_tm);
> >
> >  CPPUNIT_ASSERT_EQUAL(false, date.IsValid());
> >  CPPUNIT_ASSERT_EQUAL_MESSAGE("Year", 1970, _tm.tm_year + 1900);
> >  CPPUNIT_ASSERT_EQUAL_MESSAGE("Month", 1, _tm.tm_mon + 1);
> >  CPPUNIT_ASSERT_EQUAL_MESSAGE("Day", 1, _tm.tm_mday);
> >  CPPUNIT_ASSERT_EQUAL_MESSAGE("Hour", 0, _tm.tm_hour);
> >  CPPUNIT_ASSERT_EQUAL_MESSAGE("Minute", 59, _tm.tm_min); // Why 59
> > and not 0?
> >  CPPUNIT_ASSERT_EQUAL_MESSAGE("Second", 59, _tm.tm_sec); // Why 59
> > and not 0?
> > }
> >
> > Any quick ideas why we get 59 here and not 0?
> >
> >
> > Best regards,
> >   Dominik
> >
>
> Sorry, missed your mail.
>
> `time_t(0)` is 1970, so time_t(-1) is one second before, the values make
> sense, even if -1 is "often" (as in PDFDate) used to denote an invalid
> value.
>
> https://en.cppreference.com/w/c/chrono/time_t
>
>
> time_t(-1) is set in the constructor before parsing, and the value is
> updated to something else only on successful parsing.
> It was already the case before my patches.
>
> But does it make sense to test `date.GetTime()` if `!date.IsValid()`?
>
> AFAIK if `isValid()` is false, then there are no guarantees for the user
> of the library about the internal state.
>
> FWIW the test case is equivalent to
>
>
> void DateTest::testParseDateInvalid()
> {
>PdfString tmp("D:2012020");
>PdfDate date(tmp);
>
>CPPUNIT_ASSERT_EQUAL(false, date.IsValid());
>
>const time_t t = date.GetTime();
>CPPUNIT_ASSERT_EQUAL_MESSAGE(time_t(-1), t);
> }
>
> while you asked why it's not
>
> void DateTest::testParseDateInvalid()
> {
>PdfString tmp("D:2012020");
>PdfDate date(tmp);
>
>
>CPPUNIT_ASSERT_EQUAL(false, date.IsValid());
>
>const time_t t = date.GetTime();
>CPPUNIT_ASSERT_EQUAL_MESSAGE(time_t(0), t);
> }
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PdfDate does not comply to pdf standard

[Dominik Seichter via Podofo-users]

Hi Federico,

Updated set of patches is pushed with an additional test.

One weird issue:

void DateTest::testParseDateInvalid()
{
PdfString tmp("D:2012020");
PdfDate date(tmp);

struct tm  _tm;
memset (&_tm, 0, sizeof(struct tm));

const time_t t = date.GetTime();
localtime_r(, &_tm);

CPPUNIT_ASSERT_EQUAL(false, date.IsValid());
CPPUNIT_ASSERT_EQUAL_MESSAGE("Year", 1970, _tm.tm_year + 1900);
CPPUNIT_ASSERT_EQUAL_MESSAGE("Month", 1, _tm.tm_mon + 1);
CPPUNIT_ASSERT_EQUAL_MESSAGE("Day", 1, _tm.tm_mday);
CPPUNIT_ASSERT_EQUAL_MESSAGE("Hour", 0, _tm.tm_hour);
CPPUNIT_ASSERT_EQUAL_MESSAGE("Minute", 59, _tm.tm_min); // Why 59 and
not 0?
CPPUNIT_ASSERT_EQUAL_MESSAGE("Second", 59, _tm.tm_sec); // Why 59 and
not 0?
}

Any quick ideas why we get 59 here and not 0?


Best regards,
 Dominik

On Wed, Jan 6, 2021 at 10:18 PM Dominik Seichter 
wrote:

> Allright, let me revert my commit and apply your latest set of patches.
>
> Br
> Dominik
>
> Federico Kircheis  schrieb am Mi., 6. Jan.
> 2021, 22:14:
>
>> On 06/01/2021 20.21, Dominik Seichter wrote:
>> > Sorry, now I missed this mail while working on your previous mail and
>> patch!
>>
>> NP.
>>
>> >
>> > Could you please check the current state in SVN?
>> > I think the date handling after your previous patch was ok - do you
>> agree?
>>
>> After the previous mail I thought that D:2012 gets parsed as
>> 2012... so an error is IMHO better.
>>
>> I also do not think there are really documents that use something like
>> D:20120 instead of D:2012 or D:201201 as valid date on purpose...
>>
>> > Can you send a patch only for the PdfDate clean up please?
>>
>> You mean without adding the error-detection?
>>
>> Can do it.
>> If you take the part with the tests out it should already apply cleanly,
>> as I worked on the patch sent previously (I did not see changes on your
>> side on PDFDate, but could have missed them).
>>
>> >
>> > Thanks,
>> >   Dominik
>> >
>>
>> Federico
>>
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PdfDate does not comply to pdf standard

[Dominik Seichter via Podofo-users]

Allright, let me revert my commit and apply your latest set of patches.

Br
Dominik

Federico Kircheis  schrieb am Mi., 6. Jan.
2021, 22:14:

> On 06/01/2021 20.21, Dominik Seichter wrote:
> > Sorry, now I missed this mail while working on your previous mail and
> patch!
>
> NP.
>
> >
> > Could you please check the current state in SVN?
> > I think the date handling after your previous patch was ok - do you
> agree?
>
> After the previous mail I thought that D:2012 gets parsed as
> 2012... so an error is IMHO better.
>
> I also do not think there are really documents that use something like
> D:20120 instead of D:2012 or D:201201 as valid date on purpose...
>
> > Can you send a patch only for the PdfDate clean up please?
>
> You mean without adding the error-detection?
>
> Can do it.
> If you take the part with the tests out it should already apply cleanly,
> as I worked on the patch sent previously (I did not see changes on your
> side on PDFDate, but could have missed them).
>
> >
> > Thanks,
> >   Dominik
> >
>
> Federico
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PdfDate does not comply to pdf standard

[Dominik Seichter via Podofo-users]

Sorry, now I missed this mail while working on your previous mail and patch!

Could you please check the current state in SVN?
I think the date handling after your previous patch was ok - do you agree?

Can you send a patch only for the PdfDate clean up please?

Thanks,
 Dominik

On Wed, Jan 6, 2021 at 7:54 PM Federico Kircheis <
federico.kirch...@gmail.com> wrote:

> Hi,
>
> I've created 3 patches with svn diff to apply one after the other, feel
> free to reorg if you think the work can be splitted in some other,
> better way
>
> I've moved some implementation detail to the .cpp file, to avoid leaking
> internal details in the header file (see last patch)
> Then I've splitted the parsing function in multiple parts, as it was
> getting a little bit to complex handling everything at once.
> The third patch improves the parsing, and with that all tests are good.
>
> I've tried using the same coding style already used for PdfDate.
>
> Federico
>
> On 05/01/2021 23.18, Federico Kircheis wrote:
> > Hi Dominik, I rechecked the algorithm, D:20120530235959Z00'00' does not
> > fail anymore, i did not parse correctly Z.
> >
> >
> > D:2012010
> > D:20120
> >
> > are still failing... the solution is a bit more convoluted:
> >
> > Instead of returning a simple, boolean, ParseFixLenNumber should return
> > one of possible 3 states, something like an enum {OK, Missing, Error}.
> >
> >
> > I think something like
> >
> > 
> > enum EParseFixLenNumberResult {OK, Missing, Error};
> > EParseFixLenNumberResult PdfDate::ParseFixLenNumber(const char *,
> > unsigned int length, int min, int max, int _)
> > {
> >  if ( in == NULL || *in == '\0') return Missing;
> >  int ret = 0;
> >  for(unsigned int i=0;i >  {
> >  if ( in == NULL || !isdigit(*in)) return Error;
> >  ret = ret*10+ (*in-'0');
> >  in++;
> >  }
> >  if ( ret < min || ret > max ) return Error;
> >  ret_ = ret;
> >  return Ok;
> > }
> > 
> >
> > should do the work, but first one should decide if those optional fields
> > should really be treated as errors...
> >
> > Federico
>
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PdfDate does not comply to pdf standard

[Dominik Seichter via Podofo-users]

Hi Federico,

Thanks for the patch. I also added the test to the existing DateTest.

Unfortunately, it is failing some of the existing tests now (see updated
patch and test failure output attached).
I was reading through 3.8.3. Dates of the PDF specification, but could not
figure out, if the new behaviour is correct or not.

Especially, these dates are considered valid now, but where invalid before:
D:2012010
D:20120

And for "D:20120530235959Z00'00'" we are getting a different time value now.

Any ideas?

Best regards,
 Dominik



ominik@dominik-HP-Notebook:
~/Schreibtisch/Programming/podofo/code/podofo/build/test/unit$
./podofo-test --test DateTest
.F.F.Parse sample from pdf_reference_1_7.pdf
Parse all fields set
Parse set year
Parse set year, month
Parse set year, month, day
Parse only year and timezone set
Parse berlin




 
   
 DateTest::testCreateDateFromString
 Assertion
 
   
/home/dominik/Desktop/Programming/podofo/code/podofo/test/unit/DateTest.cpp

   43
 
 equality assertion failed
- Expected: 0
- Actual  : 1
- D:2012010

   
   
 DateTest::testDateValue
 Assertion
 
   
/home/dominik/Desktop/Programming/podofo/code/podofo/test/unit/DateTest.cpp

   79
 
 equality assertion failed
- Expected: 1
- Actual  : 0
- D:20120530235959Z

   
 
 
   
 DateTest::testAdditional
   
 
 
   3
   2
   0
   2
 




On Sat, Dec 5, 2020 at 10:15 AM Federico Kircheis <
federico.kirch...@gmail.com> wrote:

> Hello,
>
> it seems that the class PdfDate does not comply to the standard when
> parsing dates.
>
> pdf_reference_1_7.pdf
> (
> https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf)
>
> has as example "D:199812231952-08'00'" (3.8.3 Dates) as date, but
> PdfDate does not parse it correctly.
>
> See the attached patch to make, PdfDate conformant.
>
> A possible test would look like
>
> 
> struct name_date {
> std::string name;
> std::string date;
> };
>
> const name_date data[] = {
>  {"sample from pdf_reference_1_7.pdf", "D:199812231952-08'00'"},
> // UTC 1998-12-24 03:52:00
>  {"all fields set", "D:20201223195200-08'00'"},   // UTC 2020-12-23
> 03:52:00
>  {"set year", "D:2020"},   // UTC 2020-01-01 00:00:00
>  {"set year, month", "D:202001"},   // UTC 2020-01-01 00:00:00
>  {"set year, month, day", "D:20200101"},   // UTC 202001-01 00:00:00
>  {"only year and timezone set", "D:2020-08'00'"},   // UTC
> 2020-01-01 08:00:00
>  {"berlin", "D:20200315120820+01'00'"},   // UTC 2020-03-15 11:08:20
> };
>
> for (const auto& d : data) {
> std::cout << "Parse " << d.name << "\n";
> assert(PoDoFo::PdfDate(d.date).IsValid());
> }
> 
>
> but I was not sure where to put it.
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
Index: src/podofo/base/PdfDate.cpp
===
--- src/podofo/base/PdfDate.cpp	(Revision 2018)
+++ src/podofo/base/PdfDate.cpp	(Arbeitskopie)
@@ -47,17 +47,14 @@
 }
 
 PdfDate::PdfDate( const time_t & t )
-: m_bValid( false )
+: m_time( t ), m_bValid( false )
 {
-m_time = t;
 CreateStringRepresentation();
 }
 
 PdfDate::PdfDate( const PdfString & sDate )
-: m_bValid( false )
+: m_time( -1 ), m_bValid( false )
 {
-m_time = -1;
-
 if ( !sDate.IsValid() ) 
 {
 m_szDate[0] = 0;
@@ -66,11 +63,8 @@
 
 strncpy(m_szDate,sDate.GetString(),PDF_DATE_BUFFER_SIZE);
 
-struct tm _tm;
-memset( &_tm, 0, sizeof(_tm) );
-int nZoneShift = 0;
-int nZoneHour = 0;
-int nZoneMin = 0;
+struct tm _tm{};
+_tm.tm_mday = 1;
 
 const char * pszDate = sDate.GetString();
 if ( pszDate == NULL ) return;
@@ -79,51 +73,53 @@
 if ( *pszDate++ != ':' ) return;
 }
 
-if ( ParseFixLenNumber(pszDate,4,0,,_tm.tm_year) == false ) 
+// year is not optional
+if ( !ParseFixLenNumber(pszDate,4,0,,_tm.tm_year) )
 return;
-
 _tm.tm_year -= 1900;
-if ( *pszDate != '\0' ) {
-if ( ParseFixLenNumber(pszDate,2,1,12,_tm.tm_mon) == false ) 
-return;
 
+// all other values are optional, if not set they are 0-init (except mday)
+if ( ParseFixLenNumber(pszDate,2,1,12,_tm.tm_mon) )
+{
 _tm.tm_mon--;
-if ( *pszDate != '\0' ) {
-if ( ParseFixLenNumber(pszDate,2,1,31,_tm.tm_mday) == false ) return;
-if ( *pszDate != '\0' ) {
-if ( ParseFixLenNumber(pszDate,2,0,23,_tm.tm_hour) == false ) return;
-if ( *pszDate != '\0' ) {
-if ( ParseFixLenNumber(pszDate,2,0,59,_tm.tm_min) == false ) return;
-if ( *pszDate != '\0' ) {
-if ( ParseFixLenNumber(pszDate,2,0,59,_tm.tm_sec) == false ) return;
-if ( *pszDate != 

[Podofo-users] Next PoDoFo Release due to ticket #118

[Dominik Seichter via Podofo-users]

Hi PoDoFo List and Happy new year!

Melizas has provided a very interesting update of PoDoFoBrowser to Qt5.
Now, Nelson has asked in the same ticket about the next release, so he can
upload to flathub.org:
https://sourceforge.net/p/podofo/tickets/118/

Now, as I am not able to be very much involved at this point of time, I
would like to ask the list if it is ok to provide a new release?

Last release 0.9.6 was in July 2018, so might be nice to provide some new
tarballs and a tag. If it is ok for everybody, I could start the
preparation.

Best regards,
 Dominik
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Unknown font encoding

[Dominik Seichter via Podofo-users]

Hi Christophe,

Thanks. Committed as r1968.

Best regards,
 Dominik

On Thu, Feb 21, 2019 at 10:44 PM BLANCHARD Christophe <
christophe.blanch...@3ds.com> wrote:

> Hello all,
>
>
>
> A patch to fix an unknown font encoding named “SymbolSetEncoding”. I’ve
> mapped this encoding on already existing “SymbolEncoding”.
>
>
>
> I can’t furnish a test case as it is a customer test case.
>
>
>
> Thank you to take into account.
>
>
>
> Cordialement/Best Regards,
>
> Christophe Blanchard
>
>
>
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential and/or
> privileged.
>
> If you are not one of the named recipients or have received this email in
> error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this
> email and all attachments,
>
> (iii) Dassault Systèmes does not accept or assume any liability or
> responsibility for any use of or reliance on this email.
>
> Please be informed that your personal data are processed according to our
> data privacy policy as described on our website. Should you have any
> questions related to personal data protection, please contact 3DS Data
> Protection Officer at 3ds.compliance-priv...@3ds.com
>
>
> For other languages, go to https://www.3ds.com/terms/email-disclaimer
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Implementation of PNG Paeth filter

[Dominik Seichter via Podofo-users]

Hi John,

Thanks for your patch. When initially applied, your patch is causing this
compilation error for me:

/home/dominik/Desktop/Programming/podofo/podofo/src/base/PdfFiltersPrivate.cpp:
In member function ‘void PoDoFo::PdfPredictorDecoder::Decode(const char*,
PoDoFo::pdf_long, PoDoFo
::PdfOutputStream*)’:
/home/dominik/Desktop/Programming/podofo/podofo/src/base/PdfFiltersPrivate.cpp:197:58:
error:
expected primary-expression before ‘unsigned’
int a = nLeftByteIndex < 0 ? 0 : unsigned char(
m_pPrev[nLeftByteIndex] );
 ^~~~
/home/dominik/Desktop/Programming/podofo/podofo/src/base/PdfFiltersPrivate.cpp:198:33:
error:
expected primary-expression before ‘unsigned’
int b = unsigned char( m_pPrev[m_nCurRowIndex] );
^~~~
/home/dominik/Desktop/Programming/podofo/podofo/src/base/PdfFiltersPrivate.cpp:201:58:
error:
expected primary-expression before ‘unsigned’
int c = nLeftByteIndex < 0 ? 0 : unsigned char(
m_pUpperLeftPixelComponents[nCurrComponentIndex] );
 ^~~~
src/CMakeFiles/podofo_shared.dir/build.make:398: die Regel für Ziel
„src/CMakeFiles/podofo_shared.dir/base/PdfFiltersPrivate.cpp.o“ scheiterte
make[2]: ***
[src/CMakeFiles/podofo_shared.dir/base/PdfFiltersPrivate.cpp.o] Fehler 1
CMakeFiles/Makefile2:117: die Regel für Ziel
„src/CMakeFiles/podofo_shared.dir/all“ scheiterte
make[1]: *** [src/CMakeFiles/podofo_shared.dir/all] Fehler 2
Makefile:127: die Regel für Ziel „all“ scheiterte

I fixed this by replacing unsigned char(...) with static_cast(...) and committed the patch in revision 1965. Could you please
verify if this is still as intended?

Thanks,
 Dominik


On Fri, Feb 8, 2019 at 7:39 PM John Senneker  wrote:

> Hi,
>
> Please find attached a patch containing an implementation of the Paeth
> filter, which is the only PNG filter not currently implemented by PoDoFo.
> Let me know if there’s anything that could be improved!
>
>
>
> Thanks,
>
> John Senneker
>  
> Electronic mail messages entering and leaving Arup business systems are
> scanned for viruses and acceptability of content.
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Problems with pdfs generated by ArcGIS

[Dominik Seichter via Podofo-users]

hi Richard,

can you please try with the latest podofo release. 0.9.3 is abit outdated.

best regards
dominik

richard lang  schrieb am Di., 21. Aug. 2018, 06:43:

> Hi all,
>
> Having trouble with trying to load various geo-referenced pdfs generated
> by ArcGIS 10 with podofo library/utilities.
>
> With podofo 0.9.3 typically seeing an error message similar to the
> following:
>
> Error: An error 5 ocurred during uncompressing the pdf file.
>
>
> PoDoFo encounter an error. Error: 5 ePdfError_UnexpectedEOF
> Error Description: End of file was reached unxexpectedly.
> Callstack:
> #0 Error Source:
> /build/libpodofo-NltoF1/libpodofo-0.9.3/src/base/PdfParser.cpp:226
> Information: Unable to load objects from file.
> #1 Error Source:
> /build/libpodofo-NltoF1/libpodofo-0.9.3/src/base/PdfParser.cpp:334
> Information: Unable to load xref entries.
> #2 Error Source:
> /build/libpodofo-NltoF1/libpodofo-0.9.3/src/base/PdfParser.cpp:738
> #3 Error Source:
> /build/libpodofo-NltoF1/libpodofo-0.9.3/src/base/PdfTokenizer.cpp:339
>
>
>
>
> which seems to indicate an invalid xref table.
>
>
> I don't think this is a podofo bug as such, as various online pdf
> validators I've tried also flag the documents as problematic, however my
> local pdf viewing software can load and display them successfully, as can
> poppler library components.
>
> I can see a couple of similar complaints have cropped up in the mailing
> list over the years, regarding documents with bad xref tables that many
> other pdf utilities cope with but podofo refuses to load.
>
> Any suggestions on how to work around this, or what enhancements might be
> needed in podofo to cope better with this potentially non-fatal error
> condition would be appreciated.
>
> Example problem file to be found at
> https://www.dropbox.com/s/khlzgz8o2gxq89y/6090_harvest.pdf?dl=0
>
> thanks
>
> Richard.
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Fwd: Re: CVE confusion, also in Debian (was: Re: Next PoDoFo Release 0.9.6)

[Dominik Seichter via Podofo-users]

Hi Matthew et al.

I tagged the podofo-0.9.6 release already and also provided the tarball on
sourceforge. There was no official announcement though, yet.

I still think we should release 0.9.6, as the status of 0.9.6 is not worse
than 0.9.5 (PLEASE CORRECT ME IF I AM WRONG HERE!).
Nontheless, we should concentrate on fixing CVEs in a follow-up release. If
fixes are ready, I can provide another relase 0.9.7 in short time.

Is that approach fine for the participants of the discussion?

Best regards,
 Dominik

On Thu, Jul 12, 2018 at 3:16 PM, Matthew Brincke  wrote:

> Hello Mattia, hello all,
>
> firstly I apologize (especially in case the delay in reaction
> on my part is the reason PoDoFo 0.9.6 was released with CVEs
> unfixed, for some of them see below in the original message)
> for having been busy with another project and not squeezing
> this in-between, I also was unsure about you (Mattia) possibly
> being on vacation.
> As it seems to me my original e-mail (see below) was missed,
> I'm sending it again, but this time also to the podofo-users
> list because I think now that version 0.9.6 has already been
> released (IMNSHO prematurely, because of the CVEs and non-free
> code in it) it's high time the project and its users get to
> know them at last (in the Debian changelog they had been
> mistakenly declared as fixed, and I didn't dare to send a 2nd
> e-mail or a bug report: I now fear this was wrong of me, so I
> apologize).
> NB: Note that, contrary to what is in the "Original message"
> below (I left it in so the reasoning for why I didn't send it
> to the list stays intact), this has the earlier e-mail quotes
> mostly snipped (as what was in them is now done), for reasons of
> bandwidth economy, these paragraphs are already long enough ...
>
> Best regards, mabri
>
> -- Original Message --
> From: Matthew Brincke 
> To: mat...@mapreri.org
> Date: 14 June 2018 at 01:37 CEST
> Subject: Re: [Podofo-users] CVE confusion, also in Debian (was: Re: Next
> PoDoFo Release 0.9.6)
> Hello Mattia,
>
> I'm full-quoting my previous email because it was rejected by the
> list server on account of an IP-address ban and I sent it to you
> as a forward as you probably wouldn't like to get the same email
> again so I'll avoid sending it to the list, instead you get this,
> I hope this is OK. I've not pruned down this one because I don't
> know if you are regularly reading your Debian address these days,
> which I sent the the forward before (this Tuesday) to. In case of
> that being a mistake, I'm sorry.
> For the new info, please see my addition below (bad news).
> > On 12 June 2018 at 22:21 Matthew Brincke  wrote:
> >
> >
> > Hello Mattia, hello all,
> > > On 12 June 2018 at 16:25 Mattia Rizzolo  wrote:
> > >
> > >
> ... snip ...
> > > Also, what about
> > > https://security-tracker.debian.org/tracker/DLA-929-1
> > > https://security-tracker.debian.org/tracker/DLA-968-1
> > > Are they correct or they didn't fix some CVEs (like CVE-2017-5854)?
> >
> > The DLA-929-1 did not fix the CVE-2017-5854 either (the patch supposedly
> > doing that is the same change as in upstream svn r1836, so it can't).
> > The DLA-968-1 doesn't look suspect to me, though I haven't checked in
> > detail (having been busy with historical digital artifacts ;-) ).
> ... snip ...
> > > The changes should be in
> > > https://salsa.debian.org/debian/libpodofo/commits/wheezy - I would be
> > > very happy if you could double check.
> > I could probably do that tomorrow, now I'd like to get this e-mail sent.
>
> Upon detailed inspection, which I mostly did yesterday (Wednesday) like I
> promised, I found the claim in DLA-968-1's d/patches/CVE-2017-7380.patch
> that it also fixes CVE-2017-7381 to CVE-2017-7383 to be very suspect, if
> not outright mistaken.
> For CVE-2017-7381: If m_pResources in src/doc/PdfPage.cpp:609 is NULL,
> i.e. the page doesn't have resources, not even inherited ones (for those,
> cf. src/doc/PdfPage.cpp:63 to the end of the constructor), dereferencing
> it to call a method is undefined behaviour (likely crash/vulnerability).
> The patch doesn't change that, so it doesn't fix this CVE AFAICS.
>
> For CVE-2017-7382: If the dictionary which is the value of/referred to
> by the /Font entry in the /Resources dictionary exists, the patch changes
> again nothing AFAICS (is the CVE ID bound to the specific reproducer?) so
> such a /Font dictionary without /Subtype entry (in the report, queried at
> src/doc/PdfFontFactory.cpp:200) can still trigger the bug (AFAICS,
> untested).
>
> For CVE-2017-7383: The same except for /Type (in the report, queried at
> src/doc/PdfFontFactory.cpp:195) instead of /Subtype makes this unfixed.
>
> > >
> > > And if this is really going to reopen a CVE for stretch I'd need to
> > > check with the security team if they need/want to do something extra as
> > > well.
> > >
> > Please do, thank you.
> >
> > > --
> > > regards,
> > >  Mattia Rizzolo
> > >
> > Best regards, mabri
>
> 

Re: [Podofo-users] [PATCH] PoFoFo: fix CVE-2018-5296 by reducing limit in s_nMaxObjects

[Dominik Seichter via Podofo-users]

Hi Mark et al.,

I tend to agree to Marks analysis and committed a fix in revision 1925.
See also my comment to issue #6: https://sourceforge.net/p/podofo/tickets/6/

Best regards,
 Dominik

On Wed, Apr 18, 2018 at 12:26 PM, Mark Rogers 
wrote:

> Hi
>
>
>
> VeraPDF enforces the 8,388,607 indirect object limit:
>
> https://github.com/veraPDF/veraPDF-validation-profiles/
> wiki/PDFA-Part-1-rules#rule-6112-7
>
>
>
> This answer on Adobe.com expands on the reason for the limit:
>
> https://forums.adobe.com/thread/1041350 (Adobe Reader can’t load files
> with more than 8,388,607 indirect objects)
>
>
>
> This patch just changes the default – a PoDoFo library user can accept the
> risk of uncontrolled memory allocation and restore the previous max limit by
> calling PoDoFo::PdfParser::SetMaxObjectCount( std::numeric_limits::max()
> )
>
>
>
> With the 8,388,607 object count limit the maximum number of entries in
> m_offsets is 8,388,607 which uses this amount of memory for m_offsets:
>
> 32-bit: 8,388,607 * sizeof(PoDoFo::PdfParser::TXRefEntry) = 8,388,607 *
> 16 = 134 MB
>
> 64-bit: 8,388,607 * sizeof(PoDoFo::PdfParser::TXRefEntry) = 8,388,607 *
> 24 = 201 MB
>
>
>
> With the current object count limit (2**31 on 32-bit systems and 2**63 on
> 64-bit systems) then the maximum number of entries in m_offsets is less
> than this because m_offsets.max_size() = std::numeric_limits::max()
> / sizeof(PoDoFo::PdfParser::TXRefEntry) which is:
>
>
>
> 32-bit: std::numeric_limits::max() / 
> sizeof(PoDoFo::PdfParser::TXRefEntry)
> = 2**32 / 16 = 268,435,456 (requires entire 32-bit address space)
>
> 64-bit: std::numeric_limits::max() / 
> sizeof(PoDoFo::PdfParser::TXRefEntry)
> = 2 **64 / 24 = 7.6 x 10e17 (requires entire 64-bit address space)
>
>
>
> Related: I don’t think PoDoFo checks the maximum number of objects when
> writing so it can produce PDFs that Adobe Reader can’t read.
>
>
>
> Best Regards
>
> Mark
>
>
>
> --
>
> Mark Rogers - mark.rog...@powermapper.com
>
> PowerMapper Software Ltd - www.powermapper.com
>
> Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
>
>
>
>
>
> Hello Mark, hello all,
>
>
>
> > On 15 April 2018 at 22:06 Mark Rogers  wrote:
>
> >
>
> >
>
> > Hi
>
> >
>
> >
>
> > Here’s a simple patch for CVE-2018-5296 – it reduces the limit returned
>
> > by GetMaxObjectCount from std::numeric_limits::max() to 8,388,607 which
>
> > is the limit for for the maximum number of indirect objects specified
>
> > in Table C.1 in Appendix C.2 Architectural Limits in PDF 32000-1:2008
>
> >
>
> the standard says there the limits are 32-bit systems whereas PoDoFo
>
> uses 64-bit types in many places, therefore I'm feeling a bit uneasy
>
> with the patch: Can anyone please shed some more light on this issue?
>
>
>
> >
>
> > Best Regards
>
> >
>
> >
>
> > Mark
>
> >
>
> Best regards, mabri
>
>
>
>
>
>
>
> *From: *Mark Rogers 
> *Date: *Sunday, 15 April 2018 at 21:06
> *To: *"podofo-users@lists.sourceforge.net"  sourceforge.net>
> *Subject: *[Podofo-users] [PATCH] PoFoFo: fix CVE-2018-5296 by reducing
> limit in s_nMaxObjects
>
>
>
> Hi
>
>
>
> Here’s a simple patch for CVE-2018-5296 – it reduces the limit returned by
> GetMaxObjectCount from std::numeric_limits::max() to 8,388,607
> which is the limit for for the maximum number of indirect objects specified
> in Table C.1 in Appendix C.2 Architectural Limits in PDF 32000-1:2008
>
>
>
> Best Regards
>
> Mark
>
>
>
> --
>
> Mark Rogers - mark.rog...@powermapper.com
>
> PowerMapper Software Ltd - www.powermapper.com
>
> Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PdfParser unit tests

[Dominik Seichter via Podofo-users]

Hi Mark,

Thanks for this amazing test suite! I know, it is only a start for the huge
complex PdfParser, but I think it is a very good start. I included the
tests in the build with revision 1926.

They were running fine for me on Linux with the latest changes für #6 and
#7. I just had to include  and change due to new MaxObjectCount.

Best regards,
 Dominik

On Wed, Apr 18, 2018 at 7:52 PM, Mark Rogers 
wrote:

> Hi
>
>
>
> Here are the unit tests for PoDoFo::PdfParser I’ve been working on. I’ve
> just included the .cpp and .h files rather than a patch since they’re new
> files.
>
>
>
> I’ve not included a patch for CMakeLists.txt  – but I think all that’s
> needed is adding ParserTests.cpp to the CMakeLists.txt file for the unit
> tests (CppUnit takes care of everything else)
>
>
>
> What’s tested:
>
>- CVE-2017-8053, CVE-2015-8981, CVE-2017-5853, CVE-2018-5296
>CVE-2017-8787, CVE-2018-5295 CVE-2017-8378
>- Stress testing of ReadXRefSubsection( nFirstObject, nNumObjects )
>with lots of different values for nFirstObject and nNumObjects
>- Stress testing of ReadXRefSubsection with different values supplied
>to PdfParser::SetMaxObjectCount
>- Testing other PdfParser functions for infinite recursion,
>out-of-memory handling etc
>- See comments in ParserTests.h
>- 2k lines of code but still lots more that can be tested…
>
>
>
> Test results
>
>- Stack overflow in ReadXRefContents and ReadXRefStreamContents see
>https://sourceforge.net/p/podofo/tickets/7/
>
>- If this is patched (I have a patch) then the tests run successfully
>on Windows 10 with VC++ 2015 and macOS 10.11 with XCode 8/Clang and
>AddressSanitizer enabled
>- There’s a problem on macOS 10.13 (a SIGKILL when allocating a lot of
>memory) but it’s probably a macOS problem (10.13 is very buggy)
>
>
>
> Not tested:
>
>- Win64 build
>- Linux with GCC - might need a small change to get low memory tests
>to work – see comment in canOutOfMemoryKillUnitTests() at end of
>ParserTests.cpp
>
>
>
> Best Regards
>
> Mark
>
>
>
> --
>
> Mark Rogers - mark.rog...@powermapper.com
>
> PowerMapper Software Ltd - www.powermapper.com
>
> Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] CVE-2017-5853 and CVE-2017-6844 testing (overflow fixed, but unhandled exception present)

[Dominik Seichter via Podofo-users]

Hi Mark,

Thanks for your patch. Committed as revision 1921.

I would also include the unit  test into the source tree once you submit
them. Worthcase would be to disable the execution with CPPUNIT in the
Header file.

Best regards,
 Dominik

On Sat, Apr 14, 2018 at 9:29 AM, Mark Rogers 
wrote:

> It's actual unit tests (a new tests/unit/ParserTest.cpp file) and most of
> the tests are for PdfParser::ReadXRefSubsection (responsible for
> CVE-2015-8981, CVE-2017-5853, CVE-2017-5855, CVE-2017-6844, CVE-2018-5296 -
> 14% of the CVEs discovered in PoDoFo)
>
> I'll submit the new tests next week - my main concern is adding a new .CPP
> and .H file to the build lists risks breaking the build very close to
> release.
>
> A safer option (until 0.9.6 is released) might be adding the new unit test
> files without changing the build - and anyone that's running tests can
> patch their build locally to include the new tests.
>
> Best Regards
> Mark
>
> --
> Mark Rogers - mark.rog...@powermapper.com
> PowerMapper Software Ltd - www.powermapper.com
> Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
>
> On 13/04/2018, 21:58, "Mattia Rizzolo"  wrote:
>
> On Fri, Apr 13, 2018 at 02:09:40PM +, Mark Rogers wrote:
> > If I can also submit the parser unit tests now, but I was planning
> > to wait until 0.9.6 release was complete
>
> If you have actual unit tests (i.e., patches to tests/unit, or even
> within tests/ only, and not external reproducers), I'd recommend
> submitting them, and I would also recommend libpodofo maintainers to
> accept them (as really, more tests can't possibly be a bad thing…).
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'
> :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH] Compilation fix under ubuntu 16.04

[Dominik Seichter via Podofo-users]

Thanks! Committed as revision 1919.

On Fri, Apr 13, 2018 at 11:41 PM, Francesco Pretto  wrote:

> Hello,
>
> I just tested compilation on ubuntu 16.04. It's not compiling with this
> error:
>
> /home/ceztko/projects/current/PoDoFo/src/base/PdfObjectStreamParserObject.
> cpp:
> In member function ‘void
> PoDoFo::PdfObjectStreamParserObject::ReadObjectsFromStream(char*,
> PoDoFo::pdf_long, PoDoFo::pdf_int64, PoDoFo::pdf_int64, const
> ObjectIdList&)’:
> /home/ceztko/projects/current/PoDoFo/src/base/PdfObjectStreamParserObject.
> cpp:98:23:
> error: ‘numeric_limits’ is not a member of ‘std’
>  if( lFirst >= std::numeric_limits::max() - lOff )
>
> The attached patch just include #include  which seems the
> correct header where to find std::numeric_limits[1].
>
> Cheers,
> Francesco
>
> [1] http://en.cppreference.com/w/cpp/types/numeric_limits
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] RC1 - Windows builds 'PODOFO_VERSION_PATCH" value

[Dominik Seichter via Podofo-users]

Hi Oliver,

Thanks for informing us. I was never aware of this fact. For the real
release we will again have a version schema working on Windows.

Best regards,
 Dominik

On Mon, Apr 9, 2018 at 5:26 PM, Olivier Mascia  wrote:

> Hello,
>
> For your information, this:
>
> SET(PODOFO_VERSION_PATCH "6-rc1" CACHE STRING "Patchlevel part of PoDoFo
> version number")
>
> breaks resource compiling for Windows builds because the value "6-rc1" is
> not numeric.
> (Easy enough for me to patch only locally for purpose of building, but
> wanted to report).
>
> --
> Best Regards, Meilleures salutations, Met vriendelijke groeten,
> Olivier Mascia
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo 0.9.6-rc1 ready for download

[Dominik Seichter via Podofo-users]

Hi all!

I definitly did not want punish Francesco or deliberately not include his
patches! But I hope you all know this :-)

The main goal of this long awaited release candidate was to get some more
speed into PoDoFo again and think that was achieved. Today we found and
fixed already an i386 compilation error and an error with doxygen
documentation generation. I am also looking forward to the build results
from debian experimental!

Regarding the patches: If Matthew finds some time to review and include
some more patches, which are considered important, I will happily prepare
another release candidate.
@Matthew, Francesco: Is there anything particular important which we should
include into the release? Are you able to integrate some more stuff until
next Friday? Then I would try to prepare 0.9.6-rc2 next Friday?

Best regards,
 Dominik

On Sun, Apr 8, 2018 at 9:16 PM, Francesco Pretto  wrote:

> On 8 April 2018 at 21:06, Matthew Brincke  wrote:
> >
> > Could you please consider the following: I don't think the project
> should punish
> > Francesco Pretto by rejection of his not-yet-reviewed patches submitted
> on February 22,
> >
>
> Matthew, don't worry: I think I got enough review for the patches I
> posted. Some were included but others won't be applied and on those I
> got enough explanation (I already know some were possibly
> controversial). If I think some of those patches still deserve to be
> included, I will post them updated at a later stage.
>
> Cheers,
> Francesco
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo 0.9.6-rc1 ready for download

[Dominik Seichter via Podofo-users]

Sure! Thanks, committed as revision 1916.

Best regards,
 Dominik

On Sun, Apr 8, 2018 at 4:21 PM, Mattia Rizzolo <mat...@mapreri.org> wrote:

> On Sun, Apr 08, 2018 at 02:12:32PM +0200, Dominik Seichter via
> Podofo-users wrote:
> > The first release candidate for PoDoFo 0.9.6 can be downloaded from here:
> > https://sourceforge.net/projects/podofo/files/podofo/
> 0.9.6/podofo-0.9.6-rc1.tar.gz/download
> >
> > Only critical patches will be integrated before release from now on.
>
> Not critical, but I'd fine nice if you could fix these last few spelling
> errors :)
>
> Patch attached!
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] PoDoFo 0.9.6-rc1 ready for download

[Dominik Seichter via Podofo-users]

Hi,

I committed a fix as revision 1915 to trunk. I hope this fixes the build
error. Could you please verify this? I do not have an i386 system arround.

Thanks && Best regards,
 Dominik

On Sun, Apr 8, 2018 at 4:06 PM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Sun, Apr 08, 2018 at 02:12:32PM +0200, Dominik Seichter via
> Podofo-users wrote:
> > The first release candidate for PoDoFo 0.9.6 can be downloaded from here:
> > https://sourceforge.net/projects/podofo/files/podofo/
> 0.9.6/podofo-0.9.6-rc1.tar.gz/download
> >
> > Only critical patches will be integrated before release from now on.
>
> Building it on i386 fails:
>
> [ 65%] Building CXX object test/unit/CMakeFiles/podofo-
> test.dir/StringTest.cpp.o
> cd "/build/libpodofo-0.9.6~rc1/obj-i686-linux-gnu/test/unit" &&
> /usr/lib/ccache/c++  -DPODOFO_HAVE_GCC_SYMBOL_VISIBILITY
> -I"/build/libpodofo-0.9.6~rc1/obj-i686-linux-gnu"
> -I"/build/libpodofo-0.9.6~rc1" -I/usr/include/i386-linux-gnu
> -I/usr/include/cppunit -I/usr/include/lua5.1 
> -I"/build/libpodofo-0.9.6~rc1/src"
> -I/usr/include/freetype2 -I/src -I/src/os  -g -O2 
> -fdebug-prefix-map=/build/libpodofo-0.9.6~rc1=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wall -Woverloaded-virtual -Wswitch-enum -Wcast-qual
> -Wwrite-strings -Wredundant-decls -Wreorder -Wno-deprecated-declarations
>  -W -fvisibility=hidden -g -o CMakeFiles/podofo-test.dir/StringTest.cpp.o
> -c "/build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp"
> /build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp: In function 'void
> print(PoDoFo::pdf_utf16be*, PoDoFo::pdf_long)':
> /build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:47:36: warning:
> format '%li' expects argument of type 'long int', but argument 2 has type
> 'PoDoFo::pdf_long {aka int}' [-Wformat=]
>  printf("start lLen=%li\n", lLen);
> ^
> In file included from /usr/include/cppunit/TestCase.h:6:0,
>  from /usr/include/cppunit/TestCaller.h:5,
>  from /usr/include/cppunit/extensions/HelperMacros.h:9,
>  from /build/libpodofo-0.9.6~rc1/
> test/unit/StringTest.h:24,
>  from /build/libpodofo-0.9.6~rc1/
> test/unit/StringTest.cpp:21:
> /build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp: In member function
> 'void StringTest::TestLibUnistringInternal(const char*, long int, long
> int)':
> /build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:73:5: error: no
> matching function for call to 'assertEquals(long int, PoDoFo::pdf_long&,
> CppUnit::SourceLine, const char [66])'
>  CPPUNIT_ASSERT_EQUAL_MESSAGE( "Comparing length of output buffer
> after utf8 -> utf16 conversion.", lLenUtf16 + 1, result1 );
>  ^
> /usr/include/cppunit/TestAssert.h:127:6: note: candidate: template T> void CppUnit::assertEquals(const T&, const T&, CppUnit::SourceLine,
> const string&)
>  void assertEquals( const T& expected,
>   ^~~~
> /usr/include/cppunit/TestAssert.h:127:6: note:   template argument
> deduction/substitution failed:
> /build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:73:5: note:   deduced
> conflicting types for parameter 'const T' ('long int' and 'PoDoFo::pdf_long
> {aka int}')
>  CPPUNIT_ASSERT_EQUAL_MESSAGE( "Comparing length of output buffer
> after utf8 -> utf16 conversion.", lLenUtf16 + 1, result1 );
>  ^
> /build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:78:5: error: no
> matching function for call to 'assertEquals(long int, PoDoFo::pdf_long&,
> CppUnit::SourceLine, const char [74])'
>  CPPUNIT_ASSERT_EQUAL_MESSAGE( "Comparing length of output buffer
> after utf8 -> utf16 -> utf8 conversion.", lLenUtf8 + 1, result2 );
>  ^
> /usr/include/cppunit/TestAssert.h:127:6: note: candidate: template T> void CppUnit::assertEquals(const T&, const T&, CppUnit::SourceLine,
> const string&)
>  void assertEquals( const T& expected,
>   ^~~~
> /usr/include/cppunit/TestAssert.h:127:6: note:   template argument
> deduction/substitution failed:
> /build/libpodofo-0.9.6~rc1/test/unit/StringTest.cpp:78:5: note:   deduced
> conflicting types for parameter 'const T' ('long int' and 'PoDoFo::pdf_long
> {aka int}')
>  CPPUNIT_ASSERT_EQUAL_MESSAGE( "Comparing length of output buffer
> after utf8 -> utf16 -> utf8 conversion.", lLenUtf8 + 1, result2 );
>  ^
> test/unit/CMakeFiles/podofo-test.dir/build.make:377: recipe for target
> 'test/unit/CMakeFiles/podofo-test.dir/StringTest.cpp.o'

Re: [Podofo-users] manpage for podofobox

[Dominik Seichter via Podofo-users]

Thanks. Committed as revision 1914. Will be part of the release.

On Sun, Apr 8, 2018 at 3:14 PM, Mattia Rizzolo  wrote:

> It seems like in Debian we have an extra manpage for podofobox, compared
> to what's in the new man/ directory.
>
> It's not much, but could you please commit it as well?
>
> >>
> .TH "PODOFOBOX" "1" "2010-12-09" "PoDoFo" "podofobox"
> .PP
> .SH NAME
> podofobox \- set the media, crop, bleed, trim, and art box on pages of a
> PDF
> file\.
> .PP
> .SH SYNOPSIS
> \fBpodofobox\fR [inputfile] [outpufile] [box] [left] [bottom] [width]
> [height]
> .PP
> .SH DESCRIPTION
> .B podofobox
> is one of the command line tools from the PoDoFo library that provide
> several
> useful operations to work with PDF files\. It can set the media, crop,
> bleed,
> trim, and art box on pages of a PDF file\.
> .PP
> .SH "SEE ALSO"
> .BR podofocountpages (1),
> .BR podofocrop (1),
> .BR podofoencrypt (1),
> .BR podofogc (1),
> .BR podofoimg2pdf (1),
> .BR podofoimgextract (1),
> .BR podofoimpose (1),
> .BR podofomerge (1),
> .BR podofoincrementalupdates (1),
> .BR podofopages (1),
> .BR podofopdfinfo (1),
> .BR podofotxt2pdf (1),
> .BR podofotxtextract (1),
> .BR podofouncompress (1),
> .BR podofoxmp (1)
> .PP
> .SH AUTHOR
> .PP
> PoDoFo is written by Dominik Seichter  and others\.
> .PP
> This manual page was written by Oleksandr Moskalenko 
> for
> the Debian Project (but may be used by others)\.
> 
>
> (of course feel free to adapt/improve it, I haven't reviewed it)
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] PoDoFo 0.9.6-rc1 ready for download

[Dominik Seichter via Podofo-users]

Hi everybody,

The first release candidate for PoDoFo 0.9.6 can be downloaded from here:
https://sourceforge.net/projects/podofo/files/podofo/0.9.6/podofo-0.9.6-rc1.tar.gz/download

Only critical patches will be integrated before release from now on.

Best regards,
 Dominik
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] [PATCH] PdfRect: Add normalization of coordinates

[Dominik Seichter via Podofo-users]

Hi Francesco,

Thanks for your contribution. Patch committed as revision 1911.

Best regards,
 Dominik

On Sat, Apr 7, 2018 at 7:58 PM, Francesco Pretto  wrote:

> According to Pdf Reference 1.7, 3.8.4 Rectangles:
>
> "Note: Although rectangles are conventionally specified by their
> lower-left and upperright
> corners, it is acceptable to specify any two diagonally opposite corners.
> Applications
> that process PDF should be prepared to normalize such rectangles in
> situations
> where specific corners are required."
>
> PdfRect class defines a rectangle by lower-left point plus width/height.
> Normalization
> of coordinates from array of reals is currently not performed and will
> result in rectangles
> with negative width/height when x1 > x2 and/or y1 > y2, which appeared to
> happen in my test
> documents. The attached patch performs the required normalization by
> swapping coordinates
> in such cases.
>
>
> ---
>   src/base/PdfRect.cpp | 31 ++-
>   1 file changed, 26 insertions(+), 5 deletions(-)
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] About fix for CVE-2017- 6845 (Was: Re: Next PoDoFo Release 0.9.6)

[Dominik Seichter via Podofo-users]

Hi zyx

Yes that makes sense. I was also wandering why we do have logic checks only
in debug.

Would you be so kind and remove the #ifdef NDEBUG? i do not have acess to
svn right now.

Thanks
Dominik

Am 22.02.2018 09:30 schrieb "zyx" :

> On Wed, 2018-02-21 at 21:51 +0100, Dominik Seichter wrote:
> > It should always be legal to call this:
> > PODOFO_RAISE_LOGIC_IF( m_stack.empty(), "Can get current
> > graphicsstate!" );
> >
> > As it translates to:
> > if( m_stack.empty() ) {
> >  throw ...
> > }
>
> Hi,
> the macro is fine, the problem is whether you compile Release or Debug
> version of the PoDoFo. From src/base/PdfError.h:
>
>#ifndef NDEBUG
>// Woo for double-negatives. We define PODOFO_RAISE_LOGIC_IF unless
> we've been told not to by NDEBUG.
>#define PODOFO_RAISE_LOGIC_IF( x, y ) { if (x) throw
> ::PoDoFo::PdfError( ePdfError_InternalLogic, __FILE__, __LINE__, y ); };
>#else
>#define PODOFO_RAISE_LOGIC_IF( x, y ) {};
>#endif
>
> My suggestion was to remove that '#ifndef NDEBUG' and define the
> PODOFO_RAISE_LOGIC_IF with the 'throw' always, regardless of the build
> type.
>
> Bye,
> zyx
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Next PoDoFo Release 0.9.6

[Dominik Seichter via Podofo-users]

Hi everybody,

As you have seen, I was not yet able to prepare a release candidate last
week. There are still a few mails I want to go through before preparing the
RC. So, I would want to shift above timeline by approximately one month,
Feel free to provide and integrate more fixes, as long as the release
candidate is not prepared yet.

Best regards,
 Dominik

On Sun, Jan 14, 2018 at 8:48 PM, Dominik Seichter <
domseich...@googlemail.com> wrote:

> Hello PoDoFo developers and supporters,
>
> The last version of PoDoFo was released almost a year ago on February 2nd
> 2017. I have seen many patches on the mailing list and also many commits to
> SVN over the last year. So, I think it is time for a new PoDoFo release
> 0.9.6.
>
> As there might have been patches, which either Zyx or I have missing, I
> would suggest the following release time line.
>
> - Please submit (or resubmit) all the patches which should go into the
> release until February 11th 2018.
> - I will try to integrate the patches into SVN trunk and prepare PoDoFo
> 0.9.6-rc1!
> - Let's test the release candidate for about 4 weeks and head for the
> final release aroundt March 11th
>
> If necessary, we can delay the release for a few weeks or do a second
> release candidate.
>
> Best regards,
>  Dominik
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] About fix for CVE-2017- 6845 (Was: Re: Next PoDoFo Release 0.9.6)

[Dominik Seichter via Podofo-users]

Hi zyx,

Thanks for the solid analysis. I agree and reverted the fix I did in 1873.
I am not sure how we PODOFO_RAISE_LOGIC_IF can cause such an error?

It should always be legal to call this:
PODOFO_RAISE_LOGIC_IF( m_stack.empty(), "Can get current graphicsstate!" );

As it translates to:
if( m_stack.empty() ) {
 throw ...
}

What for tools do you have in mind? Of course we convert the call to the
macro to using real if-statements here.

Best regards,
 Dominik



On Sun, Feb 18, 2018 at 2:37 PM, zyx <z...@gmx.us> wrote:

> On Fri, 2018-01-26 at 17:37 +0100, Dominik Seichter via Podofo-users
> wrote:
> > https://security-tracker.debian.org/tracker/CVE-2017-6845
> > -> I have committed a fix that should address this issue. Maybe
> > someone on the list can review my fix.
>
> Hi,
> I had a look on this, mainly because of the added warnings in compile
> time (the compiler warning is correct, checking for 'NULL == ' is
> wrong, because it means dereferencing such NULL pointer first, which
> can and should lead to a crash on its own) and also in runtime of
> test/unit/podofo-test, and when I run the test case of the CVE, then it
> is not triggered here, the call finishes with the following exception
> instead:
>
>Error: An error 8 ocurred during processing the pdf file
>
>PoDoFo encountered an error. Error: 8 ePdfError_InternalLogic
>   Error Description: An internal error occurred.
>   Callstack:
>   #0 Error Source: .../tools/podofocolor/graphicsstack.cpp:38
>  Information: Can push copy on graphicsstack! Stack is empty!
>
> I also added a debug printf() into the PdfColor::operator=() and it is
> never called with a NULL '' here.
>
> That led me to the place of the exception and it uses
> PODOFO_RAISE_LOGIC_IF(). Looking into its definition, then it throws
> the exception only if the library is compiled with debugging, otherwise
>  it does nothing.
>
> I believe the correct change is to revert the revision 1873 and change
> the usage of PODOFO_RAISE_LOGIC_IF() in the public tools. This macro
> should be used only on places where PoDoFo has complete control of, not
> on places which depend on generic/user data. The PDF processing is all
> about generic data, thus even better change might be to enable
> PODOFO_RAISE_LOGIC_IF() always, not only for debug builds.
>
> Am I right? Which of the two options makes more sense from your point
> of view?
>
> Thanks and bye,
> zyx
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Bug tracker (was: Re: Next PoDoFo Release 0.9.6)

[Dominik Seichter via Podofo-users]

Hi All,

Thanks for the hint zyx! I think I was able to reconfigure the ticket
system in sourceforge.

Can you please check: https://sourceforge.net/p/podofo/tickets

This should be working now!

Best regards,
 Dominik

On Fri, Feb 2, 2018 at 9:44 AM, zyx <z...@gmx.us> wrote:

> On Fri, 2018-01-26 at 17:37 +0100, Dominik Seichter via Podofo-users
> wrote:
> > BTW: Just found this on Sourceforge: https://sourceforge.net/p/
> podofo/bugs/?source=navbar
> > Anybody has experience with this? Shall we just use this feature?
>
> Hi,
> it seems SF has enabled the tickets for the project, but you have
> disabled ticket creation for some reason, because only admins can add
> tickets there. I didn't find where the settings for it is.
>
> I would remove all three categories and use just one [1], but you might
> probably contact SF support ( SF.Net Ops <sfnet_...@slashdotmedia.com>)
> to help with it, at least with the permissions to logged-in users being
> able to create tickets. This part works for my other project on SF,
> but  I created it only recently, which might be the reason.
> Bye,
> zyx
>
> [1] https://sourceforge.net/p/podofo/_list/tickets
> gives 3 parts, while for example litePDF has there only one:
> https://sourceforge.net/p/litepdf/_list/tickets
> which works fine and is:
> https://sourceforge.net/p/litepdf/tickets/
> I do not know whether the actual name of the tickets group matters.
> You can "Add New..." (on the right side of the bar when you are
> logged in as the admin)->Tickets.
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Next PoDoFo Release 0.9.6

[Dominik Seichter via Podofo-users]

Hi Matthew et al.,



On Fri, Jan 26, 2018 at 11:35 PM, Matthew Brincke <ma...@mailbox.org> wrote:

> [ Left Dominik in To to help him follow this thread, fixed text typos ]
>
> Hello Dominik, hello all,
>
> > Dominik Seichter via Podofo-users has written on 26 January 2018 at
> 17:37:
> >
> >
> > Hi Mattia,
> >
> > Thanks for the good summary! Let me comment on the open issues.
> >
> > Unfixed security issues:
> ... snip ...
> >
> > https://security-tracker.debian.org/tracker/CVE-2017-8053
> > -> Please see proposed patch in attachment. Can somebody test/review?
> >
>
> In line 13 of the patch, there are typos, it should be "already visited",
> line 14 doesn't really fit (which object?), and in general, shouldn't
> there be a maximum recursion depth which is checked for, to prevent a
> stack overflow? AFAICS there is no standard function/method to check
> available stack space ;-( ...
>
>
Yes, typos fixed and line 14 removed. Also agreed, that a maximum check
might be nice. Still, the patch should address the main issue of been
vulnerable to certain PDF files.



> > https://security-tracker.debian.org/tracker/CVE-2017-8054
> > -> This was fixed by zyx in revision: 1872. I have a test PDF
> >for this and cannot reproduce this issue anymore.
>
> The fix was provided by Matthias Brinke <podofo-sec-cont...@mailbox.org>
> (stands for "PoDoFo security contributor", I'm a friend of his) on the
> Debian Bug Tracking System: https://bugs.debian.org/860995
>
>
Agreed, my statement should better have been: "zyx committed a fix for
this" :-) Thanks for the fix!



> >
> > Plus this one without CVE that was reported in this ML:
> > https://blogs.gentoo.org/ago/2017/02/01/podofo-null-
> pointer-dereference-in-pdfinfoguessformat-pdfinfo-cpp/
>
> This is *not* fixed yet. I also don't understand why it didn't get
> a CVE entry.
>
> > (CVE-2017-8054 had a tentative patch)
> > -> Seems same as above and seems fixed.
>
> The CVE, yes, contrary to the other one without a CVE entry.
>
> >
> > A threading problem:
> >  https://sourceforge.net/p/podofo/mailman/message/35915862/
> > -> There is no need to make the matrix for XObjects static, so I made
> >it a normal member. Same for s_procset in PdfCanvas. So should be
> >fixed with my last commit.
>
> As you said in your next e-mail to the ML the double-checked locking
> pattern
> isn't fixed yet: https://sourceforge.net/p/podofo/mailman/message/
> 36205920/
>
> >
> > A copyright issue:
> >  https://sourceforge.net/p/podofo/mailman/message/35633858/
> > -> We still do not have a fix for this.
> >
>
> I recommend libunistring2 to fix it, but haven't used it yet.
>

I try to have a look at libunistring2.


>
> >  [snip]


Best regards,
 Dominik
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Re: [Podofo-users] Thread safety

[Dominik Seichter via Podofo-users]

Hi Michall,

Sorry for the terribly late reply to your email.
I replaced the static arrays with local variables which is totally fine for
these case: https://sourceforge.net/p/podofo/code/1875/

The invalid double checked locking for singletons needs a separate fix
though.

Best regards,
 Dominik

On Tue, Jun 27, 2017 at 10:17 PM, Michal Sudolsky 
wrote:

> Hi,
>
> There are many initialised static local variables which is thread-safe
> only in C++11 and above what is ok.
>
> What is not ok is that there are two class member static variables which
> are initialised lazily in some member function.
> These cases are definitely not thread-safe. There should be mutex at least
> or they could be simply declared non-static.
>
> PdfCanvas:
>
>  private:
>> /** The procset is the same for all
>>  *  PdfContents objects
>>  */
>> *static **PdfArray s_procset;*
>
>
>
>
>>  const PdfArray & PdfCanvas::GetProcSet()
>> {
>> if( s_procset.empty() )
>> {
>> s_procset.push_back( PdfName( "PDF" ) );
>> s_procset.push_back( PdfName( "Text" ) );
>> s_procset.push_back( PdfName( "ImageB" ) );
>> s_procset.push_back( PdfName( "ImageC" ) );
>> s_procset.push_back( PdfName( "ImageI" ) );
>> }
>> return s_procset;
>> }
>
>
> PdfXObject:
>
>  private:
>> *static **PdfArray  s_matrix;*
>
>
> void PdfXObject::InitXObject( const PdfRect & rRect, const char*
>> pszPrefix )
>> {
>> PdfVariantvar;
>> ostringstream out;
>> PdfLocaleImbue(out);
>
>
>
> // Initialize static data
>> if( s_matrix.empty() )
>> {
>> // This matrix is the same for all PdfXObjects so cache it
>> s_matrix.push_back( PdfVariant( static_cast(PODOFO_
>> LL_LITERAL(1)) ) );
>> s_matrix.push_back( PdfVariant( static_cast(PODOFO_
>> LL_LITERAL(0)) ) );
>> s_matrix.push_back( PdfVariant( static_cast(PODOFO_
>> LL_LITERAL(0)) ) );
>> s_matrix.push_back( PdfVariant( static_cast(PODOFO_
>> LL_LITERAL(1)) ) );
>> s_matrix.push_back( PdfVariant( static_cast(PODOFO_
>> LL_LITERAL(0)) ) );
>> s_matrix.push_back( PdfVariant( static_cast(PODOFO_
>> LL_LITERAL(0)) ) );
>> }
>
>
>
> This DLCP singleton is also not thread-safe on weakly ordered processors:
>
> const PdfEncoding* PdfEncodingFactory::GlobalPdfDocEncodingInstance()
>> {
>> if(!s_pDocEncoding) // First check
>> {
>> Util::PdfMutexWrapper wrapper( PdfEncodingFactory::s_mutex );
>>
>> if(!s_pDocEncoding) // Double check
>> s_pDocEncoding = new PdfDocEncoding();
>> }
>> return s_pDocEncoding;
>> }
>
> Can be fixed in C++11 http://preshing.com/20130930/double-checked-locking-
> is-fixed-in-cpp11/
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[Podofo-users] Next PoDoFo Release 0.9.6

[Dominik Seichter via Podofo-users]

Hello PoDoFo developers and supporters,

The last version of PoDoFo was released almost a year ago on February 2nd
2017. I have seen many patches on the mailing list and also many commits to
SVN over the last year. So, I think it is time for a new PoDoFo release
0.9.6.

As there might have been patches, which either Zyx or I have missing, I
would suggest the following release time line.

- Please submit (or resubmit) all the patches which should go into the
release until February 11th 2018.
- I will try to integrate the patches into SVN trunk and prepare PoDoFo
0.9.6-rc1!
- Let's test the release candidate for about 4 weeks and head for the final
release aroundt March 11th

If necessary, we can delay the release for a few weeks or do a second
release candidate.

Best regards,
 Dominik
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users