Re: [Podofo-users] Bugs with outlines and podofomerge
I created two sample pdf files. When you merge them with podofomerge in order "first.pdf", "second.pdf" then outlines from second.pdf are not clickable. On Wed, Feb 21, 2018 at 9:41 PM, Michal Sudolsky wrote: > Yes seems this is fixed in latest revision. But now I tried to merge some > pdf. Outlines were merged but these which come from second pdf were not > clickable. When I merged them in reverse order all outlines were clickable. > That second pdf were generated by "pdfTeX-1.40.17", other info string "This > is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version > 6.2.2". > > On Mon, Dec 18, 2017 at 10:21 AM, zyx wrote: > >> On Sun, 2017-12-17 at 17:29 +0100, Michal Sudolsky wrote: >> > I changed only this one line: >> > >> > -m_pNext = new PdfOutlineItem( pObj, NULL, this ); >> > +m_pNext = new PdfOutlineItem( pObj, m_pParentOutline, this >> > ); >> > >> >> Hi, >> this is not a patch, but okay. I took a file without outlines and one >> with outlines and used podofomerge to merge them. The resulting PDF >> file had those outlines, recognized by an acrobat reader and by evince, >> and both were able to work with them. I didn't do your suggested >> change, because I wanted to test it first. If you've any test .pdf >> files where it doesn't work, then feel free to share them (mine were >> generated by PoDoFo itself). >> >> > Seems this is already fixed in newest source at svn, I have 0.9.5 >> >> Right, the development version contains some fixes. I made the above >> test with the svn checkout at revision 1863. >> >> I suggest you to use the svn checkout, which will save your time, and >> it also makes it super-simple to provide usable patches, like when you: >> >>$ cd podofo-trunk-checkout/ >>$ svn diff >../podofo.patch >> >> The default `svn diff` didn't use the -p parameter of the diff command, >> which is also useful when applying older patches, but I do not know the >> current state, maybe they begun to use it. It's not a big deal, just a >> nice to have part of the patch. They do provide unified (-u) patches, >> which contain some context of the change. >> 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 >> > > first.pdf Description: Adobe PDF document second.pdf Description: Adobe PDF document -- 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] Wrong limits in Name Trees
These warnings are irrelevant. Here is code which does not produce warnings:
PdfMemDocument doc;
for(int i = 0; i < 66; i++)
{
char name[10];
sprintf(name, "%02i", i);
doc.AddNamedDestination(PdfDestination(doc.GetObjects().CreateObject(
PdfArray()), &doc), name);
}
doc.SetWriteMode(ePdfWriteMode_Clean);
doc.Write("doc.pdf");
Also attached whole main.cpp file and patch.txt from "svn diff" output.
-PdfNameTreeNode( NULL, pChild1 ).SetLimits();
-PdfNameTreeNode( NULL, pChild2 ).SetLimits();
+PdfNameTreeNode( m_pParent != NULL ? m_pParent : this, pChild1
).SetLimits();
+PdfNameTreeNode( this, pChild2 ).SetLimits();
I tested this with latest (
http://svn.code.sf.net/p/podofo/code/podofo/trunk/) podofo revision 1890
where is still this bug.
As I probably wrote there is problem not passing parent nodes to these
constructors and then limits are not set in right way.
Pdf contents before patch:
7 0 obj
<<
/Limits [ (00) (65) ] *<- should be [(00) (32)]*
/Names [ (00) 4 0 R (01) 8 0 R (02) 9 0 R (03) 10 0 R (04) 11 0 R
(05) 12 0 R (06) 13 0 R (07) 14 0 R (08) 15 0 R (09) 16 0 R
(10) 17 0 R (11) 18 0 R (12) 19 0 R (13) 20 0 R (14) 21 0 R
(15) 22 0 R (16) 23 0 R (17) 24 0 R (18) 25 0 R (19) 26 0 R
(20) 27 0 R (21) 28 0 R (22) 29 0 R (23) 30 0 R (24) 31 0 R
(25) 32 0 R (26) 33 0 R (27) 34 0 R (28) 35 0 R (29) 36 0 R
(30) 37 0 R (31) 38 0 R (32) 39 0 R ]
>>
...
73 0 obj
<< *<- here missing but Limits key is required by pdf
spec, here should b**e /Limits [ (33) (65) ]*
/Names [ (33) 40 0 R (34) 41 0 R (35) 42 0 R (36) 43 0 R (37) 44 0 R
(38) 45 0 R (39) 46 0 R (40) 47 0 R (41) 48 0 R (42) 49 0 R
(43) 50 0 R (44) 51 0 R (45) 52 0 R (46) 53 0 R (47) 54 0 R
(48) 55 0 R (49) 56 0 R (50) 57 0 R (51) 58 0 R (52) 59 0 R
(53) 60 0 R (54) 61 0 R (55) 62 0 R (56) 63 0 R (57) 64 0 R
(58) 65 0 R (59) 66 0 R (60) 67 0 R (61) 68 0 R (62) 69 0 R
(63) 70 0 R (64) 71 0 R (65) 72 0 R ]
>>
Why is this not right is clear from pdf specification about this "Limits"
key. This key is required here and first value should be the "smallest"
name (lexically) and second the "biggest" name within "Names". These names
are actually strings like suggests parentheses.
Here when pdf reader searches for name "50" it will look only in object 7
because limits are from "00" to "65", it will not find it here so decides
name "50" actually does not exists even it is in object 73.
*After patch:*
7 0 obj
<<
/Limits [ (00) (32) ]
/Names [ (00) 4 0 R (01) 8 0 R (02) 9 0 R (03) 10 0 R (04) 11 0 R
(05) 12 0 R (06) 13 0 R (07) 14 0 R (08) 15 0 R (09) 16 0 R
(10) 17 0 R (11) 18 0 R (12) 19 0 R (13) 20 0 R (14) 21 0 R
(15) 22 0 R (16) 23 0 R (17) 24 0 R (18) 25 0 R (19) 26 0 R
(20) 27 0 R (21) 28 0 R (22) 29 0 R (23) 30 0 R (24) 31 0 R
(25) 32 0 R (26) 33 0 R (27) 34 0 R (28) 35 0 R (29) 36 0 R
(30) 37 0 R (31) 38 0 R (32) 39 0 R ]
>>
endobj
...
73 0 obj
<<
/Limits [ (33) (65) ]
/Names [ (33) 40 0 R (34) 41 0 R (35) 42 0 R (36) 43 0 R (37) 44 0 R
(38) 45 0 R (39) 46 0 R (40) 47 0 R (41) 48 0 R (42) 49 0 R
(43) 50 0 R (44) 51 0 R (45) 52 0 R (46) 53 0 R (47) 54 0 R
(48) 55 0 R (49) 56 0 R (50) 57 0 R (51) 58 0 R (52) 59 0 R
(53) 60 0 R (54) 61 0 R (55) 62 0 R (56) 63 0 R (57) 64 0 R
(58) 65 0 R (59) 66 0 R (60) 67 0 R (61) 68 0 R (62) 69 0 R
(63) 70 0 R (64) 71 0 R (65) 72 0 R ]
>>
endobj
This looks much better. Limits are ok.
This is minimalistic code which does not produce 100% valid pdf because
there are no pages for example. But is simple to add one
using "doc.GetPagesTree()->CreatePage(...)".
It is also possible to create more complex real world example with some
outlines or links (with named destinations) to pages which well known pdf
reader cannot see due to bad limits and this is also how I found this bug,
so I created this minimalistic example to see actual bug and how patch
fixed it.
On Mon, Dec 18, 2017 at 9:20 AM, zyx wrote:
> On Sun, 2017-12-17 at 17:08 +0100, Michal Sudolsky wrote:
> > From code around seems it really does not depend what parent is here
> > set, I followed logic above and did it like this (this is all what I
> > changed):
> >
> > old:
> > > PdfNameTreeNode( NULL, pChild1 ).SetLimits();
> > > PdfNameTreeNode( NULL, pChild2 ).SetLimits();
> >
> > new:
> > > PdfNameTreeNode(m_pParent != NULL ? m_pParent : this,
> > > pChild1).SetLimits();
> > > PdfNameTreeNode(this, pChild2).SetLimits();
>
> Hi,
> just few things:
> a) you accidentally replied only to me, not to the list
> b) this is far from being a patch, you should attach it, because your
>HTML message body breaks patch in several ways (and even if it's not
>HTML message, I still prefer patches as attachments, which avoids
>issues with mail readers)
> c) that didn't change anything here, the resulting PDF is the same
> d) I guess you are aware that the code snippet you provided in
>the first email o
Re: [Podofo-users] Next PoDoFo Release 0.9.6
On 21 February 2018 at 21:55, Dominik Seichter via Podofo-users wrote: > Feel free to provide and integrate more fixes, as long as the release > candidate is not prepared yet. > > Hi Dominik, I'm a new comer and I recently began working with PoDoFo. Since it seems I'm using some untested code paths, I found some bugs which I already patched myself in my private git clone of the svn repository. Also I added some convenience accessibility methods and improvements, most of them are one-liners, or very short anyway. What do you recommend me to send these patches? Can I send git formatted patches to the mailing list? Will you be able to apply them? I have the feeling "git am" is able to apply git formatted patches without a git repository, but I have yet to try it. Thank you, 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
Re: [Podofo-users] Next PoDoFo Release 0.9.6
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)
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 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 == &rhs' 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 '&rhs' 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] Bugs with outlines and podofomerge
Yes seems this is fixed in latest revision. But now I tried to merge some pdf. Outlines were merged but these which come from second pdf were not clickable. When I merged them in reverse order all outlines were clickable. That second pdf were generated by "pdfTeX-1.40.17", other info string "This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) kpathsea version 6.2.2". On Mon, Dec 18, 2017 at 10:21 AM, zyx wrote: > On Sun, 2017-12-17 at 17:29 +0100, Michal Sudolsky wrote: > > I changed only this one line: > > > > -m_pNext = new PdfOutlineItem( pObj, NULL, this ); > > +m_pNext = new PdfOutlineItem( pObj, m_pParentOutline, this > > ); > > > > Hi, > this is not a patch, but okay. I took a file without outlines and one > with outlines and used podofomerge to merge them. The resulting PDF > file had those outlines, recognized by an acrobat reader and by evince, > and both were able to work with them. I didn't do your suggested > change, because I wanted to test it first. If you've any test .pdf > files where it doesn't work, then feel free to share them (mine were > generated by PoDoFo itself). > > > Seems this is already fixed in newest source at svn, I have 0.9.5 > > Right, the development version contains some fixes. I made the above > test with the svn checkout at revision 1863. > > I suggest you to use the svn checkout, which will save your time, and > it also makes it super-simple to provide usable patches, like when you: > >$ cd podofo-trunk-checkout/ >$ svn diff >../podofo.patch > > The default `svn diff` didn't use the -p parameter of the diff command, > which is also useful when applying older patches, but I do not know the > current state, maybe they begun to use it. It's not a big deal, just a > nice to have part of the patch. They do provide unified (-u) patches, > which contain some context of the change. > 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] Wrong limits in Name Trees
On Mon, Dec 18, 2017 at 9:20 AM, zyx wrote: > On Sun, 2017-12-17 at 17:08 +0100, Michal Sudolsky wrote: > > From code around seems it really does not depend what parent is here > > set, I followed logic above and did it like this (this is all what I > > changed): > > > > old: > > > PdfNameTreeNode( NULL, pChild1 ).SetLimits(); > > > PdfNameTreeNode( NULL, pChild2 ).SetLimits(); > > > > new: > > > PdfNameTreeNode(m_pParent != NULL ? m_pParent : this, > > > pChild1).SetLimits(); > > > PdfNameTreeNode(this, pChild2).SetLimits(); > > Hi, > just few things: > a) you accidentally replied only to me, not to the list > b) this is far from being a patch, you should attach it, because your >HTML message body breaks patch in several ways (and even if it's not >HTML message, I still prefer patches as attachments, which avoids >issues with mail readers) > c) that didn't change anything here, the resulting PDF is the same > Regarding this yes as I wrote pdf reader will reject this pdf because there are no pages, try to add page and you will see both pdf same in pdf reader. What is here different is part of internal pdf structure which I pasted into these emails from text editor and in case before patch is this structure not as it should be and in case of more elaborated example there can be seen differences also in pdf viewer. > d) I guess you are aware that the code snippet you provided in >the first email of this thread is generating warnings on console: >"Unsupported object given to PdfDestination::Init of type >DictionaryDone" > > 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] Accessing the images of one page?
> Le 21 févr. 2018 à 18:02, Dmitry Salychev a écrit : > > Olivier, > > ah, I see. > Anyway, your idea is to get any PDF file, scan it page by page and perform an > action if there is a specific image (QR code) placed on any page. > Am I correct. ? Precisely, yes. That’s something I do today using another toolkit than PoDoFo, but I would like to switch to PoDoFo for the future. -- Best regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia (from mobile device) smime.p7s Description: S/MIME cryptographic signature -- 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] Accessing the images of one page?
Olivier, ah, I see. Anyway, your idea is to get any PDF file, scan it page by page and perform an action if there is a specific image (QR code) placed on any page. Am I correct? Regards, - Dmitry -- 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] Accessing the images of one page?
Dmitry, > Le 21 févr. 2018 à 17:37, Dmitry Salychev a écrit : > > (this is a copy of my previous reply which, for some reason, wasn't posted on > the mailing list yesterday O_o) Indeed. I guess the list is moderated by hand to filter out noise. Or Sourceforge really has email backlog issues since they moved last week and had pretty much everything down for multiple days. I received minutes ago the echo of another post I made yesterday. > First of all, you've to know what kind of image you're going to access. They > usually can be stored in a PDF file two ways: XObject image or inline one. > Does it make any sense? It will start making sense soon and slowly, now that I have put my hands on the ISO32000_2008.pdf from Adobe website and I have started reading bits and blurbs here and there. The main situation for this image access is when processing PDF files made by scanners, so where each PDF page is essentially one single bitmap. Will these be XObjects or inline images or could be both. I still have to learn here. Though I will have to make it work too for custom built PDF made of text, drawings and eventually images added the way PoDoFo adds them (by DrawImage). Of course in this case only those images are expected to be found: I'm not looking to get a bitmap rendering of the whole page (à la Ghostscript). -- 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
Re: [Podofo-users] Accessing the images of one page?
Hi, Olivier. (this is a copy of my previous reply which, for some reason, wasn't posted on the mailing list yesterday O_o) First of all, you've to know what kind of image you're going to access. They usually can be stored in a PDF file two ways: XObject image or inline one. Does it make any sense? Regards, - Dmitry Regards, - Dmitry On Tue, Feb 20, 2018 at 5:26 PM, Olivier Mascia wrote: > Dear all, > > The podofoimgextract tool is a good documentation on how to access all > images in a PDF file. > What I would like to do is access all the images used on one page. > I'm a bit short on documentation or sample code to get inspiration, short > of reading the Adobe PDF standard, I suppose. :) > > To understand the context, the purpose is to scan for QR barcodes on each > page and act on that page when found. The QR side is not an issue. I'm just > hardly finding my way on how to properly enumerate the images used on a > page instead of browsing all the images as a whole without consideration on > which page it is used. It probably is incredibly simple to do using the > primitives of PoDoFo, but I'm still struggling learning it deeper than at > its surface. > > If you know of a bit of code or merely a bit of documentation which might > be useful for me to read, I'm all ears. > > Thanks a lot, > -- > 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] non-free piece of code in src/base/PdfString.cpp
Replying to: https://sourceforge.net/p/podofo/mailman/message/35633858/ (Which I read from the archives as I wasn't subscribed to this list by that time) Not sure if it would fit your complete needs, along with licensing needs, but you might want to have a look to: http://utfcpp.sourceforge.net https://sourceforge.net/projects/utfcpp/ > A simple, portable and lightweight generic library for handling UTF-8 encoded > strings. > > Features > • Iterating through UTF-8 encoded strings > • Converting between UTF-8 and UTF-16/UTF-32 > • Detecting invalid UTF-8 sequences The license looks MIT-like to me. > // Copyright 2006 Nemanja Trifunovic > > /* > Permission is hereby granted, free of charge, to any person or organization > obtaining a copy of the software and accompanying documentation covered by > this license (the "Software") to use, reproduce, display, distribute, > execute, and transmit the Software, and to prepare derivative works of the > Software, and to permit third-parties to whom the Software is furnished to > do so, all subject to the following: > > The copyright notices in the Software and this entire statement, including > the above license grant, this restriction and the following disclaimer, > must be included in all copies of the Software, in whole or in part, and > all derivative works of the Software, unless such copies or derivative > works are solely in the form of machine-executable object code generated by > a source language processor. > > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT > SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE > FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, > ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > DEALINGS IN THE SOFTWARE. > */ -- 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
