Re: [Podofo-users] 0.9.5 regression, pdfImage.GetObject()->GetDictionary() throws exception
Has anyone attempted to analyze this issue using valgrind? (I have not yet). It smells like heap or stack corruption to me. On Fri, Feb 10, 2017 at 5:37 AM, Sandro Mani wrote: > > > On 08.02.2017 11:21, Sandro Mani wrote: > > > > > > However I can't reproduce it with the static library though, so it is > > definitely related to the shared library. > > > Hi > Dropping -std=c++98 "fixes" the issue for me. Is there a reason for > using -std=c++98? > > Sandro > > > > -- > 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] PdfName memory usage
Please do not introduce a global data structure like this (not thread safe,
not freed until app exits) into PoDoFo. This will be problematic for those
of us with long-lived, multi-threaded, applications. If you want a global
cache of the PdfNames, I request that you add reference counting and
protect access with a mutex (or similarly appropriate, cross-platform,
synchronization barrier).
On Fri, Jan 13, 2017 at 9:19 AM, Mark Rogers
wrote:
> Hi
>
> I think it would probably need to be a static rather than per-document,
> because you won’t always have a reference to an owner document when
> dictionaries are being modified.
>
> class PdfName
> {
> static Map< std::string, PdfName> s_nameTable;
>
> }
>
> That would mean keys are always valid (the name table would only be
> destroyed when the app exits)
>
> One issue is threading – I’m not sure what guarantees PoDoFo gives around
> threading, but this makes dictionary operations non-thread safe unless
> locking is added.
>
> Current memory layout in 32-bit windows is:
>
> class PoDoFo::PdfName size(36):
> 0 (base class PoDoFo::PdfDataType)
> 0 {vfptr} (size=4)
> 4 m_bImmutable (size=1)
> |(size=3)
> 8 std::string m_Data (size =24)
> plus
> 8 bytes HeapAlloc overhead
> 8 bytes malloc overhead
>
> Total: 36+8+8 =52 bytes per dictionary key
>
> If the std::string was changed to a ref counted pointer this would change
> to something like:
>
> class PoDoFo::PdfName size(16):
> 0 (base class PoDoFo::PdfDataType)
> 0 {vfptr} (size=4)
> 4 m_bImmutable (size=1)
> |(size=3)
> 8 std::string* m_Data (size =4)
> plus
> 8 bytes HeapAlloc overhead
> 8 bytes malloc overhead
>
> Total: 31+8+8 =32 bytes per dictionary key
>
> If the dictionary keys are changed to PdfName& or PdfName* then it changes
> to
>
> Total: 4 bytes per dictionary key (Sizeof(PdfName*) = sizeof(void*) = 4
> bytes) with no heap overhead
>
> 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
>
>
>
>
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Underflows in PdfString::GetLength, PdfString::GetUnicodeLength, PdfString::GetCharacterLength
I am also able to trigger this bug, reliably, when manipulating a PDF that
results from the merger of other PDFs, some internal PoDoFo code attempts
to create empty strings. I was hesitant to submit my hack as I did not
fully determine a root-cause for the crashes that I'm getting. For me,
PoDoFo only crashes when run under valgrind, but leaks memory (measured
other ways). Hence I was using valgrind to find the leaks, and a crash
resulted. Anyway, my "fix" is this ugly thing: (I am not submitting a
formal patch, just code for discussion):
Index: src/doc/PdfPainter.cpp
===
--- src/doc/PdfPainter.cpp (revision 1747)
+++ src/doc/PdfPainter.cpp (working copy)
@@ -749,6 +749,13 @@
PODOFO_RAISE_ERROR( ePdfError_InvalidHandle );
}
+// 2015-12-15, dennis.jenkins...@gmail.com, if sText is valid, but empty,
then DrawText()
+// will randomly crash under valgrind
+if (!sText.GetLength())
+{
+return;
+}
+
On Tue, May 17, 2016 at 4:44 PM, Matthew Brincke wrote:
> On Sun, 2016-05-08 at 17:46 +, zyx wrote:
>
> > On Sat, 2016-05-07 at 09:29 -0500, Mark Rogers wrote:>> Is the behaviour
> in PdfString intentional or should it be patched as
> >> below?
>
> > Hi,
> > (mostly :) ) no bug is intentional, one change had been done in
>
> > revision 610 and one at revision 642 (see the commit comments).
> > https://sourceforge.net/p/podofo/code/610
> > https://sourceforge.net/p/podofo/code/642
>
> > My understanding of the changes is that the expectation is that the
> > internal buffer has stored the strings in unicode with a null-
> > terminating character, which is 2 bytes long in the raw buffer.
>
>
> Hi all,
>
> please also note what I wrote on this topic in a different, earlier thread:
> Message-ID: <1999657706.870025.1453662574817.javamail.ya...@mail.yahoo.com
> >,
> archive Web URL https://sourceforge.net/p/podofo/mailman/message/34791645/
>
> titled "PdfString with negative length" where I reviewed a patch for that
> from a security researcher, and asked for some fixes to that, but
> nothing came of it, either on the list, or personally to me.
>
> > Did you manage to reproduce this with a certain PDF file content, or by
>
> > creating the PdfString instance in some code from scratch?
>
> That's also interesting for me, please share.
> > Thanks and bye,
> > zyx
>
> Best regards, mabri
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Podofo-users mailing list
> Podofo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Release 0.9.3, SVN revision
Hello. What SVN revision was used to create the official 0.9.3 release that is available for download here [1]? Gentoo Linux is still using 0.9.2. I've been building my own project against podofo svn trunk head, which is installed as 0.9.4 [2]. I am trying to build my project on a new Gentoo server that only has official packages installed, and it fails (the podofo API has subtle changes). My end goal is to coordinate with the Gentoo podofo package maintainer to publish 0.9.3 or 0.9.4. But before I do that, I want to recreate 0.9.3 from SVN and test against that. If that version does not have the API level that I need, then I want to request that Podofo publish 0.9.4 as an official release. Does this make sense? Thank you for your consideration. [1] http://podofo.sourceforge.net/download.html [2] /usr/local/lib64/libpodofo.so.0.9.4 -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] SVN commit 1587 broke ability to parse several PDFs
On Wed, Jul 2, 2014 at 1:47 PM, Mark Rogers wrote: > Hi > > > > I finally had a chance to look at this – looks like there’s a > long-standing bug in PdfParser::ReadXRefStreamContents > > > > Once called, the method assumes that all cross reference information found > by following the “Prev” keys is stored as cross ref streams (XRefStm). The > IRS test documents uses a mix of old style cross-ref tables (xref) and > cross ref streams (XRefStm) in the Prev chain. I’m guessing they’ve been > through a couple of different PDF editors. > > > > PdfTokenizer::GetNextNumber() is throwing an error because the next token > is “xref” instead of number when it reads an xref table it assumes is an > XRefStm > > > > Given that fixing this might uncover more problems, and it’s very close to > release day, I’d suggest keeping r1648 for the moment and I’ll submit a > patch after the release. > > > > Does that sound ok? > > > > Cheers > > Mark > > > > +1 That sounds like a very sensible plan to me! -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] SVN commit 1587 broke ability to parse several PDFs
On Mon, Jun 30, 2014 at 3:10 PM, zyx wrote: > > Hi, > thanks for a quick testing. I committed the patch as r1648 [1]. If > you'll find time and give it more thorough testing by Friday, then > it'll be great (you know, just in case it has any side-effects). > Thanks again and bye, > zyx > > [1] http://sourceforge.net/p/podofo/code/1648 > Hello, r1648 works fine for me, for both my quick parser test and for my full suite of unit tests for my own project. Thank you! -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] SVN commit 1587 broke ability to parse several PDFs
On Mon, Jun 30, 2014 at 2:29 PM, zyx wrote: > On Sun, 2014-06-29 at 18:56 +0200, zyx wrote: > > I think of reverting the patch, to support those "probably broken" > > files, but I'd like to hear from you too, whether the file is truly > > broken. > > Hi, > Dennis, could you try with the attached patch, preferably on current > trunk, please? It seems to survive on the file you gave a link to, but > I only tried to open it, not to modify in it or read its objects. > Thanks and bye, > zyx > > Hello Zyx, With your patch applied to a clean checkout of rev 1646, my test suite can now open every PDF that I have (various tax forms from 2009 to current). I have not attempted to make use of the contents of the files that previously failed to parse, so I do not know if they are fully intact (in PoDoFo's internal model). My quick+dirty testing tool can count the number of pages in these PDFs though (seems ok). -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Proposing release of PoDoFo 0.9.3 to July 7th, 2014
On Fri, Jun 27, 2014 at 11:26 AM, Dominik Seichter < domseich...@googlemail.com> wrote: > Hi All! > > A release on 7/7/2014 sounds good to me. I can help or even do the release > (update webpage, upload tarball). Or, if zyx wants to do the release, I can > also assist. Whatever you prefer. > > Can anyone tag the source on 7/7/2014 (or whenever you think we are > ready). I could create a tarball from this. It would also be very helpful > to me, if someone could put release notes together. > > Before you push out a release, please consider that SVN commit [1587] causes PoDoFo to throw an exception when opening some PDFs created by Adobe LiveCycle, as published on the USA's IRS (tax authority) web site. This bug / feature has not been addressed (that I know of) yet, and would potentially break PoDoFo for other users as well. I posted a bug report to this list a few days ago, including the URL of where one can obtain a pristine copy of a sample PDF that causes failure. I have 5 other PDFs that I can post if anyone wants a larger sample size. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] How to open a PDF form in editing mode.
On Fri, Jun 27, 2014 at 5:07 AM, VED PRAKASH wrote: > Hi, > >I was wondering how to open a PDF Form in editing mode, means I wan't > to read the form pdf, and should be able to fill and save it. > > There is an example of creating a Form PDF, but not to open an existing > one. > > Can anyone put some light, how to do this? > > I posted some code that I use for conducting PoDoFo form experiments to pastebin (it is a bit much to place into this mailing list). The pastebin paste is set to never expire. No warranty or guarantee. Your mileage may very. http://pastebin.com/upYiQTp6 -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] SVN commit 1587 broke ability to parse several PDFs
Hello All, I recently noticed that PoDoFo (svn rev 1642) was unable to parse several older PDFs (all obtained from the USA IRS for tax years 2011 and before). These PDFs were made with profession Adobe products, so I expect them to be conformant. I narrowed down the version of PoDoFo that causes the failure, but I have not analyzes the source code diff yet. These PDFs parsed without error under PoDoFO svn rev 1586, but failed on rev 1857 (2014-04-01, change to PdfParser.cpp). Attempting to open the document with PoDoFo::PdfMemDocument() throws "ePdfError_NoNumber". I have a total of 6 IRS tax forms for various years that all fail to open in PoDoFo (they all throw the same exception [2]), but for now, I'll just focus on one. This [1] PDF was created with "Adobe LiveCycle Designer ES 8.2" on 2010-11-22. (October 2010 revision of the 941 tax form). I suspect that PDFs are conformant (unproven hunch) and that PoDoFo 1587+ is buggy. Thoughts? Analysis? [1] http://www.irs.gov/pub/irs-prior/f941--2010.pdf [2] The following stack trace is from PoDoFo rev 1587: PoDoFo encounter an error. Error: 14 ePdfError_NoNumber Error Description: A number was expected but not found. Callstack: #0 Error Source: /tmp/podofo/src/src/base/PdfParser.cpp:226 Information: Unable to load objects from file. #1 Error Source: /tmp/podofo/src/src/base/PdfParser.cpp:289 Information: Unable to skip xref dictionary. #2 Error Source: /tmp/podofo/src/src/base/PdfParser.cpp:738 #3 Error Source: /tmp/podofo/src/src/base/PdfParser.cpp:551 Information: Unable to load /XRefStm xref stream. #4 Error Source: /tmp/podofo/src/src/base/PdfParserObject.cpp:109 Information: Object and generation number cannot be read. #5 Error Source: /tmp/podofo/src/src/base/PdfTokenizer.cpp:365 Information: xref -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Heads-Up: Drawing API to be changed within the next few weeks
On Tue, Jun 17, 2014 at 4:29 PM, Dennis Jenkins wrote: > > >> >>> Caused by drawing API change. >>> >> >> What was the rationale for removing DrawRect() and FillRect()? This >> change breaks existing, working, code. >> >> What code should I replace those with? >> >> > I changed calls to "DrawRect" to "Rectangle", and calls to "FillRect" to > "Rectangle" followed by "Fill()". If this was the incorrect solution, > please let me know. > > Maybe I missed the release notes, but this API change was frustrating. > I found your notes in the SVN commit messages. "DrawRect()" is now "Rectangle()" followed by "Stroke()" (although in my existing reports, I did not need to call Stroke, I added the call anyway, per your notes.) My project now compiles cleanly with podofo rev 1642, and my PDFs appear ok so far. I suppose that I was expecting to see some sort of organized release notes giving a brief mention to the API change details, instead of "hey, I changed stuff and merged it into trunk!". :) In any event, I wish to thank you for your contributions. Now that I have read your notes, your rationales make sense. I was just frustrated that it broke my own project. But I'm good now. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Heads-Up: Drawing API to be changed within the next few weeks
> > >> > lib/report/state/Generic-SUTA-pdf.cpp: In member function 'double >> Report_Generic_SUTA::_pdf_rpt_header(PoDoFo::PdfMemDocument*, >> PoDoFo::PdfPainter&, double) const': >> > lib/report/state/Generic-SUTA-pdf.cpp:182:7: error: 'class >> PoDoFo::PdfPainter' has no member named 'DrawRect' >> > pntr.DrawRect (x1, y, w1, h1, r1, r1); >> >^ >> > >> > lib/pdf/pdf-tools.cpp: In function 'void >> pdf_setAppearanceStreamCheckBox(PoDoFo::PdfCheckBox*)': >> > lib/pdf/pdf-tools.cpp:113:10: error: 'class PoDoFo::PdfPainter' has no >> member named 'FillRect' >> > painter.FillRect (0, xObjOff.GetPageSize().GetHeight(), >> xObjOff.GetPageSize().GetWidth(), xObjOff.GetPageSize().GetHeight()); >> > ^ >> >> Caused by drawing API change. >> >> > What was the rationale for removing DrawRect() and FillRect()? This > change breaks existing, working, code. > > What code should I replace those with? > > I changed calls to "DrawRect" to "Rectangle", and calls to "FillRect" to "Rectangle" followed by "Fill()". If this was the incorrect solution, please let me know. Maybe I missed the release notes, but this API change was frustrating. ps- the online doxygen still lists the older API. http://podofo.sourceforge.net/doc/html/classPoDoFo_1_1PdfPainter.html (FillRect() still listed). -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Heads-Up: Drawing API to be changed within the next few weeks
> lib/report/ReportBaseClass-pdf.cpp:58:15: error: 'const class > > PoDoFo::PdfError' has no member named 'what' > > ._txt (err.what()); > >^ > > Hi, > the above is caused by change of the PdfError class, it doesn't > inherit from std::exception anymore. > > > Why was this done? > > lib/report/state/Generic-SUTA-pdf.cpp: In member function 'double > Report_Generic_SUTA::_pdf_rpt_header(PoDoFo::PdfMemDocument*, > PoDoFo::PdfPainter&, double) const': > > lib/report/state/Generic-SUTA-pdf.cpp:182:7: error: 'class > PoDoFo::PdfPainter' has no member named 'DrawRect' > > pntr.DrawRect (x1, y, w1, h1, r1, r1); > >^ > > > > lib/pdf/pdf-tools.cpp: In function 'void > pdf_setAppearanceStreamCheckBox(PoDoFo::PdfCheckBox*)': > > lib/pdf/pdf-tools.cpp:113:10: error: 'class PoDoFo::PdfPainter' has no > member named 'FillRect' > > painter.FillRect (0, xObjOff.GetPageSize().GetHeight(), > xObjOff.GetPageSize().GetWidth(), xObjOff.GetPageSize().GetHeight()); > > ^ > > Caused by drawing API change. > > What was the rationale for removing DrawRect() and FillRect()? This change breaks existing, working, code. What code should I replace those with? -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Heads-Up: Drawing API to be changed within the next few weeks
Well, never mind. I just did a 100% fresh checkout of podofo (v1640), and it builds fine. So "make clean" does not make it as clean as I expected. Code from my project (which simply uses podofo) now fails to compile. I am in the middle of other development work, so I am going to revert to podofo svn rev 1600, and port my code to the new podofo later. However, I suspect that others will grumble about the API breakage... There are four errors listed below. The first indicates to me that the method "PdfDocument::CreateFont(specific args)" is declared in the header file, but not implemented. I have not verified this hypothesis. The other three build errors are attempts to call methods that were declared in the rev 1600 podofo API, but have since disappeared. /home/djenkins/code/capybara/t1/tools/pdf-dump.cpp:100: undefined reference to `PoDoFo::PdfDocument::CreateFont(char const*, bool, PoDoFo::PdfEncoding const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool)' collect2: error: ld returned 1 exit status make: *** [output/pdf-dump] Error 1 lib/report/ReportBaseClass-pdf.cpp:58:15: error: 'const class PoDoFo::PdfError' has no member named 'what' ._txt (err.what()); ^ lib/report/state/Generic-SUTA-pdf.cpp: In member function 'double Report_Generic_SUTA::_pdf_rpt_header(PoDoFo::PdfMemDocument*, PoDoFo::PdfPainter&, double) const': lib/report/state/Generic-SUTA-pdf.cpp:182:7: error: 'class PoDoFo::PdfPainter' has no member named 'DrawRect' pntr.DrawRect (x1, y, w1, h1, r1, r1); ^ lib/pdf/pdf-tools.cpp: In function 'void pdf_setAppearanceStreamCheckBox(PoDoFo::PdfCheckBox*)': lib/pdf/pdf-tools.cpp:113:10: error: 'class PoDoFo::PdfPainter' has no member named 'FillRect' painter.FillRect (0, xObjOff.GetPageSize().GetHeight(), xObjOff.GetPageSize().GetWidth(), xObjOff.GetPageSize().GetHeight()); ^ On Sun, Jun 15, 2014 at 9:44 PM, Dennis Jenkins wrote: > SVN rev 1640 fails to build on my 64-bit Gentoo Linux system (building > from SVN src, not from Gentoo portage). > > Until this evening, I was using SVN rev 1600. When 1640 failed to build > for me, I began a binary search to narrow down when the build first > failed. SVN rev 1612 builds for me, but with lots of warnings. Rev 1613 > fails with some errors, but not like the errors, nor the amount of errors, > as seen in the 1640 rev build. > > Please let me know if I can help you further. > > My testing methodology: > > djenkins@ostara ~/src/podofo/podofo-head $ svn info . | grep ^URL > URL: http://svn.code.sf.net/p/podofo/code/podofo/trunk > > djenkins@ostara ~/src/podofo/podofo-head $ svn up -r 1613 > > djenkins@ostara ~/src/podofo/podofo-head $ make clean && cmake . && make > -j4 all test > > > > SVN REV 1640 build log: > > Linking CXX executable CreationTest > CMakeFiles/CreationTest.dir/CreationTest.cpp.o: In function > `CreateUnicodeAnnotationFreeText(PoDoFo::PdfPage*, PoDoFo::PdfDocument*)': > CreationTest.cpp:(.text+0x409): undefined reference to > `PoDoFo::PdfDocument::CreateFont(char const*, bool, PoDoFo::PdfEncoding > const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool)' > CMakeFiles/CreationTest.dir/CreationTest.cpp.o: In function > `LineTest(PoDoFo::PdfPainter*, PoDoFo::PdfPage*, PoDoFo::PdfDocument*)': > CreationTest.cpp:(.text+0xc76): undefined reference to > `PoDoFo::PdfDocument::CreateFont(char const*, bool, bool, bool, > PoDoFo::PdfEncoding const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool, > char const*)' > CreationTest.cpp:(.text+0xd33): undefined reference to > `PoDoFo::PdfString::PdfString(wchar_t const*, long)' > CreationTest.cpp:(.text+0xda6): undefined reference to > `PoDoFo::PdfString::PdfString(wchar_t const*, long)' > CreationTest.cpp:(.text+0xe95): undefined reference to > `PoDoFo::PdfPainter::Rectangle(double, double, double, double, double, > double)' > CreationTest.cpp:(.text+0xffa): undefined reference to > `PoDoFo::PdfDocument::CreateFont(char const*, bool, bool, bool, > PoDoFo::PdfEncoding const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool, > char const*)' > CreationTest.cpp:(.text+0x127a): undefined reference to > `PoDoFo::PdfDocument::CreateFont(char const*, bool, bool, bool, > PoDoFo::PdfEncoding const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool, > char const*)' > CreationTest.cpp:(.text+0x1510): undefined reference to > `PoDoFo::PdfPainter::SetStrokeStyle(PoDoFo::EPdfStrokeStyle, char const*, > bool, double, bool)' > CreationTest.cpp:(.text+0x15af): undefined reference to > `PoDoFo::PdfPainter::SetStrokeStyle(PoDoFo::EPdfStrokeStyle, char const*, > bool, double, bool)' > CreationTest.cpp:(.tex
[Podofo-users] podofo patch (minor spelling error)
podofo.patch Description: Binary data -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Heads-Up: Drawing API to be changed within the next few weeks
SVN rev 1640 fails to build on my 64-bit Gentoo Linux system (building from SVN src, not from Gentoo portage). Until this evening, I was using SVN rev 1600. When 1640 failed to build for me, I began a binary search to narrow down when the build first failed. SVN rev 1612 builds for me, but with lots of warnings. Rev 1613 fails with some errors, but not like the errors, nor the amount of errors, as seen in the 1640 rev build. Please let me know if I can help you further. My testing methodology: djenkins@ostara ~/src/podofo/podofo-head $ svn info . | grep ^URL URL: http://svn.code.sf.net/p/podofo/code/podofo/trunk djenkins@ostara ~/src/podofo/podofo-head $ svn up -r 1613 djenkins@ostara ~/src/podofo/podofo-head $ make clean && cmake . && make -j4 all test SVN REV 1640 build log: Linking CXX executable CreationTest CMakeFiles/CreationTest.dir/CreationTest.cpp.o: In function `CreateUnicodeAnnotationFreeText(PoDoFo::PdfPage*, PoDoFo::PdfDocument*)': CreationTest.cpp:(.text+0x409): undefined reference to `PoDoFo::PdfDocument::CreateFont(char const*, bool, PoDoFo::PdfEncoding const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool)' CMakeFiles/CreationTest.dir/CreationTest.cpp.o: In function `LineTest(PoDoFo::PdfPainter*, PoDoFo::PdfPage*, PoDoFo::PdfDocument*)': CreationTest.cpp:(.text+0xc76): undefined reference to `PoDoFo::PdfDocument::CreateFont(char const*, bool, bool, bool, PoDoFo::PdfEncoding const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool, char const*)' CreationTest.cpp:(.text+0xd33): undefined reference to `PoDoFo::PdfString::PdfString(wchar_t const*, long)' CreationTest.cpp:(.text+0xda6): undefined reference to `PoDoFo::PdfString::PdfString(wchar_t const*, long)' CreationTest.cpp:(.text+0xe95): undefined reference to `PoDoFo::PdfPainter::Rectangle(double, double, double, double, double, double)' CreationTest.cpp:(.text+0xffa): undefined reference to `PoDoFo::PdfDocument::CreateFont(char const*, bool, bool, bool, PoDoFo::PdfEncoding const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool, char const*)' CreationTest.cpp:(.text+0x127a): undefined reference to `PoDoFo::PdfDocument::CreateFont(char const*, bool, bool, bool, PoDoFo::PdfEncoding const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool, char const*)' CreationTest.cpp:(.text+0x1510): undefined reference to `PoDoFo::PdfPainter::SetStrokeStyle(PoDoFo::EPdfStrokeStyle, char const*, bool, double, bool)' CreationTest.cpp:(.text+0x15af): undefined reference to `PoDoFo::PdfPainter::SetStrokeStyle(PoDoFo::EPdfStrokeStyle, char const*, bool, double, bool)' CreationTest.cpp:(.text+0x164e): undefined reference to `PoDoFo::PdfPainter::SetStrokeStyle(PoDoFo::EPdfStrokeStyle, char const*, bool, double, bool)' CreationTest.cpp:(.text+0x16ed): undefined reference to `PoDoFo::PdfPainter::SetStrokeStyle(PoDoFo::EPdfStrokeStyle, char const*, bool, double, bool)' CreationTest.cpp:(.text+0x178c): undefined reference to `PoDoFo::PdfPainter::SetStrokeStyle(PoDoFo::EPdfStrokeStyle, char const*, bool, double, bool)' CMakeFiles/CreationTest.dir/CreationTest.cpp.o:CreationTest.cpp:(.text+0x182b): more undefined references to `PoDoFo::PdfPainter::SetStrokeStyle(PoDoFo::EPdfStrokeStyle, char const*, bool, double, bool)' follow CMakeFiles/CreationTest.dir/CreationTest.cpp.o: In function `RectTest(PoDoFo::PdfPainter*, PoDoFo::PdfPage*, PoDoFo::PdfDocument*)': CreationTest.cpp:(.text+0x1ac9): undefined reference to `PoDoFo::PdfDocument::CreateFont(char const*, bool, PoDoFo::PdfEncoding const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool)' CreationTest.cpp:(.text+0x1c7e): undefined reference to `PoDoFo::PdfPainter::Rectangle(double, double, double, double, double, double)' CreationTest.cpp:(.text+0x1dff): undefined reference to `PoDoFo::PdfPainter::Rectangle(double, double, double, double, double, double)' CreationTest.cpp:(.text+0x1efb): undefined reference to `PoDoFo::PdfPainter::Rectangle(double, double, double, double, double, double)' CreationTest.cpp:(.text+0x1fe9): undefined reference to `PoDoFo::PdfPainter::Rectangle(double, double, double, double, double, double)' CreationTest.cpp:(.text+0x2100): undefined reference to `PoDoFo::PdfPainter::Rectangle(double, double, double, double, double, double)' CreationTest.cpp:(.text+0x2114): undefined reference to `PoDoFo::PdfPainter::FillAndStroke(bool)' CreationTest.cpp:(.text+0x2224): undefined reference to `PoDoFo::PdfPainter::Rectangle(double, double, double, double, double, double)' CreationTest.cpp:(.text+0x2238): undefined reference to `PoDoFo::PdfPainter::FillAndStroke(bool)' CreationTest.cpp:(.text+0x23d4): undefined reference to `PoDoFo::PdfPainter::Fill(bool)' CMakeFiles/CreationTest.dir/CreationTest.cpp.o: In function `TextTest(PoDoFo::PdfPainter*, PoDoFo::PdfPage*, PoDoFo::PdfDocument*)': CreationTest.cpp:(.text+0x2614): undefined reference to `PoDoFo::PdfDocument::CreateFont(char const*, bool, PoDoFo::PdfEncoding const*, PoDoFo::PdfFontCache::EFontCreationFlags, bool)' CreationTest.cpp:(.text+0x29
Re: [Podofo-users] Dominik, are you ok?
I use SVN on my personal development server, and I am unlikely to change that. However, for contributing to open source projects, I do prefer github. Github makes is much easier for me to maintain a private branch, share my changes, and pull in patches from others, including non-main-line patches. In addition to what everyone else says about github, I like that github makes it easier to catalog one's contributions to open-source software... for the day when a resume needs to be updated :) I very much appreciate the work that Dominik and others have put into PoDoFo. I will happily contribute any patches that I develop if I think that anyone else would find them useful, no matter what SCM the project uses. On Mon, May 12, 2014 at 7:35 AM, Matias Piipari wrote: > GitHub certainly makes it easier to deal with outside open source > contributors than a mailing list & patches. Arguably it also encourages > people to actually contribute. Pull requests are one example of what helps, > and not only don't you need to accept all PRs, but you also get a record of > the discussions around open and previously closed PRs in a nice form, with > comments that can concern individual code lines etc or even make small > formatting related edits directly in GitHub, all in all very helpful for > both maintaining and contributing end in open source projects. > > Another thing that's rather nice about GitHub is that you can connect it > to continuous integration setups, so that for instance a PR gets built > against the master branch and is confirmed to not break building or tests, > as presented with a small status marker beside the commit. > > > > On Sun, May 11, 2014 at 7:52 PM, Dominik Seichter < > domseich...@googlemail.com> wrote: > >> Hi Dennis, Hi all, >> >> Thanks for the caring emails. I am fine and of good health. >> As I did mention at a few times, I currently do not have much time to >> deal with PoDoFo. I am very glad that zyx supported me over the last few >> month with integrating patches, as I cannot do this at the moment. Also, I >> cannot say whether this will change soon and if I will have more time for >> developing PoDoFo in the near future. The reason is, I am busy with my job, >> which is at the moment not PDF related. So there is simply no time left for >> OpenSource work (also because of a busy private life ...). >> >> If someone else is interested in committing patches into the repository, >> I will be glad to also give other commit access. I try to at least review >> commits on the svn mailing list as they come. Other also look on this list, >> so it should be ok if we have a few more committers. Just drop me an email, >> if you want to be added to the project. >> >> It would also be great if someone would want to prepare a new release >> tarball, update the webpage and put the release on sourceforge (maybe also >> freecode.org ...). >> >> Regarding the github discussion: I do not see any advantages of a move to >> github in the current situation. Surely, pull requests are a great tool. >> But, we need people to look at patches and even if I could integrate them >> in github with just one click, I still would need the time to review and >> test patches. If other active developers prefer a move to github, I would >> not object this either. Still, I do not see any advantages at the moment. >> >> Kindest regards, >> Dominik >> >> >> >> On Sun, May 11, 2014 at 3:41 PM, Dennis Jenkins < >> dennis.jenkins...@gmail.com> wrote: >> >>> Hello All, >>> >>> Dominik Seichter has not posted since 2014-04-13 [1]. Does anyone >>> on this list know if he is ok? When he disappeared for a week or so I >>> though that he might be on vacation; but he's been gone for almost a month. >>> >>> There are several patches waiting to be merged (mine included). >>> Does anyone else on this list of authority to commit changes to the >>> sorceforge podofo repository? >>> >>> I propose that if we do not hear from Dominik my the end of May, >>> that we consider forking (even if temporary) PoDoFo so that we can merge >>> our various changes and continue to move the project forwards. I certainly >>> hope that this is not necessary though. I hope that Dominik is ok and will >>> return to continue to guide/manage PoDoFo. >>> >>> >>> [1] http://sourceforge.net/p/podofo/mailman/message/32220953/ >>> >>> >>>
Re: [Podofo-users] patch to implement form field inheritance (ISO 32000:2008, Section 12.7.3.1, table 220, page #432)
On Sun, May 11, 2014 at 11:31 AM, zyx wrote: > On Mon, 2014-04-28 at 15:19 -0500, Dennis Jenkins wrote: > > The following works for me. I can now access all of the fields on the > > Arizona A1-QRT PDF form. I humbly submit this minor patch for > > peer-review and hopeful inclusion into PoDoFo. > > Hi, > I committed "the patch" as r1599 [1]. > > Dennis, the next time, please attach the patch rather than paste it into > the email. Even not large, it was painful to "apply" "the patch" by > hand. Thanks for your understanding. > Bye, > zyx > > [1] http://sourceforge.net/p/podofo/code/1599 > > zyx, Thank you for committing the patch. I was not expecting it to be committed without feedback, that is why I pasted it inline instead of attaching it. Again, thank you. -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Dominik, are you ok?
Hello All, Dominik Seichter has not posted since 2014-04-13 [1]. Does anyone on this list know if he is ok? When he disappeared for a week or so I though that he might be on vacation; but he's been gone for almost a month. There are several patches waiting to be merged (mine included). Does anyone else on this list of authority to commit changes to the sorceforge podofo repository? I propose that if we do not hear from Dominik my the end of May, that we consider forking (even if temporary) PoDoFo so that we can merge our various changes and continue to move the project forwards. I certainly hope that this is not necessary though. I hope that Dominik is ok and will return to continue to guide/manage PoDoFo. [1] http://sourceforge.net/p/podofo/mailman/message/32220953/ -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Splicing PDFs with AcroForms, NeedsAppearances, mysterious file size shrinkage, Adobe Reader behavior
Hello all (but mostly directed to Leonard), A few days ago I described [1] some odd behavior that I am having with Adobe Reader consuming PDFs generated by my project. To avoid hijacking Christophe's original thread, I am starting a new one. At a high-level, my goal is to use PoDoFo to splice together pages from various PDFs which are US tax forms, fill in the data, save the resulting PDF and have the filled-in form fields "just work" in Adobe Reader (eg, be visible and still editable) and have Adobe Reader NOT prompt the user to save the file when the user attempts to exit. Secondly, I noticed that if I allow Adobe Reader to save the PDF, it shrinks in half (sometimes). I want to know why, so that I can optimize the size of my PDFs without needing Adobe Reader (my code runs on Linux as part of a web service). Leonard suggested that my PDF is malformed and that Adobe Reader is offering to repair/save it in this case. After much experimentation and staring at "podofobrowser" and "podofopdfinfo diffs" of the pre- and post- PDFs, I am not 100% convinced that this is the case. In my code, I must set the "NeedsApperances" dictionary element of the "/AcroForm" to "true", or my fields will not be visible in Adobe Reader. I then need to populate the appearance stream, per section 12.7.3.3 of ISO 32000:2008 (herein referred to as "the spec"). When Adobe Reader saves my PDF, this dictionary key disappears, and every field element gains a key called "AP", with a child key of "N". This is discussed in 12.7.3.3 of the spec on page #435, first complete paragraph. If I omit adding the key for "NeedsApperances" to the AcroForm, Adobe Reader will no longer offer to save my PDF, but my field values are no longer visible. Therefore, I suspect that Adobe wants to save the PDF in order to apply/generate the per-field appearance stream. QUESTION 1: Is the above hypothesis valid? I generate my PDFs by creating an empty PDF in memory, and "inserting" pages from other PDFs. This results in a PDF with no "Fields" in the "/AcroForm/Fields" array. Adobe Reader populates the "Fields" array when it saves the PDF. However, the count of elements in the "Fields" array does not match the actual count of fields. For example, Adobe Reader places 176 elements into this array, but when I enumerate all fields on all pages using the PoDoFo API (with my patch to handle inherited fields), I count 212. I have not completed an exhaustive comparison of the "Fields" arrays yet to determine if the discrepancy is due to the inherited form fields (typically check boxes) or not. I wrote a routine to populate the "Fields" array myself (with all 212 items), but Adobe Reader rebuilds it with on 176 items. If I do not set the "NeedsApperances" flag, Adobe Reader never offers to save the PDF on exit, so this array is not rebuilt in this case. QUESTION 2: How does Adobe Reader determine which fields need to be in the "/AcroForm/Fields" array? Adobe Reader seems to not care that the "/AcroForm" is missing (its presence or absence does not affect when Adobe Reader offers to save the form). Yet section 12.7.2 of the spec states that the "/AcroForm" is required. QUESTION 3: How do we reconcile section 12.7.2 with Adobe Reader's behavior? Which is "correct" (or did I misunderstand the ISO)? The content of the "Fields -> element -> AP -> N" key is an "/XObject". The data stream created by Adobe Reader for it looks complicated. QUESTION 4: Assuming the answer to Question #1 is "yes", Do you have any suggestions on how I can compute the required XObject in code? I just want to check a checkbox or place simple text into a text field. When Adobe Reader does save the PDF, and depending on which source form(s) are in it, the resulting PDF might shrink in size considerably. A cursory look with podofobrowser shows that Adobe Reader has heavily modified "Pages -> Kids[page] -> Contents[]". In my current testing PDF, the original has one element in page #0 Contents, with a compressed length of 20443. Adobe Reader's version has 8 array elements, each with approximately 2K of compressed XObject data. QUESTION 5: Why does Adobe Reader tinker with this part of a PDF when saving it? Ok, that was rhetorical - I assume that it does so so the the file will be smaller, and it also sets the "linearized" flag. The question should be stated: What rules does Adobe Reader follow when deciding if/how to refactor the actual page layout. QUESTION 6: Why does refactoring the XObject components make the file so much smaller (200K vs 450K for example). In some cases, the file size savings are significant. If I knew what rules Adobe Reader followed, I might attempt to write a routine to apply the same changes using PoDoFo (and share it with the community). Thank you for your time. [1] http://sourceforge.net/p/podofo/mailman/message/32302847/ -- Is
Re: [Podofo-users] How to reduce Pdf size
On Sun, May 4, 2014 at 5:06 PM, Leonard Rosenthol wrote: > Adobe Reader doesn’t re-save PDFs – so perhaps you mean Adobe Acrobat?? > > Leonard > > Hello Leonard, I do mean "Adobe Reader XI" on 32-bit Windows XP. I'm not editing the PDF, exactly. Let me provide an example. The IRS provides a four-page PDF for the "941" report, and a second report (addenda) called the "Schedule B". Only two pages of the 941 have actual "pdf form" data. My program will create a new (empty) PDF, open the 941, splice in two of the four pages, splice in the Schedule B (if needed), and then fill in the form fields with the proper data. I must also embed another font and create an appearance stream (you helped me with this logic a few years ago). The software will then save the PDF. If I open this PDF in Adobe Reader, it looked correct (form fields are filled in). However, if I attempt to exit/close Adobe Reader, it prompts me "Do you want to save changes to XXX.pdf before closing?" (even if I changed nothing while Adobe Reader was open). If I decline, then Adobe Reader exits and nothing special happens. If I elect to "save my changes", then the resulting PDF on disk is smaller then the original, a new top-level section called "/Metadata" is created, and the "/Acroform" is altered. I have yet to determine what gets removed from the PDF that makes it smaller, but I suspect that it is the font that I had to add earlier. If I don't add that font, then the fields that I filled in are not visible in Adobe Reader unless the individual field is selected by the user (input focus). I can repeat the above with the other forms that my software will populate (Arizona A1-QRT and Arizona UC-018). (Federal 941 report, file size difference is not much) $ ls -l ./tmp/report*.pdf -rw-r--r-- 1 djenkins djenkins 654315 May 4 22:59 ./tmp/report.pdf -rw-r--r-- 1 djenkins djenkins 606551 May 4 23:00 ./tmp/report2.pdf (AZ UC-018 report, size difference is significant) $ ls -l ./tmp/report*.pdf -rw-r--r-- 1 djenkins djenkins 415754 May 4 23:01 ./tmp/report.pdf -rw-r--r-- 1 djenkins djenkins 206989 May 4 23:01 ./tmp/report2.pdf -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] How to reduce Pdf size
On Sun, May 4, 2014 at 7:13 AM, Christophe Meyer < christophe.meyer.2...@gmail.com> wrote: > Hello Podofo users, > > I am developping a simple software. As a first basis, I would like to > duplicate a pdf file that has been created by my printer (a scanned > document). It consists of a file of 40 pages. It weights 10 Mb and each > page of the pdf document is an image of a scanned document’s page. > > In my program, I am just copying each page from the original pdf (I load > it in a PdfMemDocument) and then inserts it in another PdfMemDocument with > InsertPage. > > I just do a Write() at the end. > > The file created at the end weighs more than 500 MB!! I searched a lot of > topics. I saw one talking about disabling the embedded fonts. First, I do > not know how to do this as I am not using any fonts and there is no options > in the Write() function in the PdfMemDocument class. So I do not know where > to specify not to embed fonts. Second, I am not convinced this is the > problem as it is only images in the file and no strings attached. Isn’t it > a problem of bad compression of the image? Then How should I proceed? > > I am really sorry for the dumb question but as you can see, I am a > beginner in C++. I will really appreciate any kind of help. > > Christophe > > Hello Christophe, This is not a dumb question. I am dealing with this too, expect my source documents are PDFs of federal and state tax forms (ex: USA Federal 941, Arizona UC-018, etc...). My resulting PDFs are significantly larger than the originals. Further, if I open my derived PDF in Adobe Reader, then save it, the resulting PDF is much smaller. I have been analyzing both PDFs in "podofo-browser" to see if I can determine why/how Adobe Reader makes it much smaller. Unfortunately, I have not had success yet. Addressing this issue is not a super high priority for me at this time. I have considered writing a program that uses podofo and tinyxml2 to dump a PDF as an XML document. I could then dump both PDFs and run them through an XML diff utility. Please Humor me and do an experiment. Open your huge PDF in adobe reader, then save it. Does the file size shrink significantly? -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] patch to implement form field inheritance (ISO 32000:2008, Section 12.7.3.1, table 220, page #432)
Anyone?
Would anyone with commit access consider committing this patch?
On Mon, Apr 28, 2014 at 3:19 PM, Dennis Jenkins wrote:
> The following works for me. I can now access all of the fields on the
> Arizona A1-QRT PDF form. I humbly submit this minor patch for peer-review
> and hopeful inclusion into PoDoFo.
>
>
> djenkins@ostara ~/src/podofo $ svn diff src/doc/PdfPage.cpp
> Index: src/doc/PdfPage.cpp
> ===
> --- src/doc/PdfPage.cpp (revision 1597)
> +++ src/doc/PdfPage.cpp (working copy)
> @@ -553,8 +553,7 @@
> {
> pAnnot = const_cast(this)->GetAnnotation( i );
> // Count every widget annotation with a FieldType as PdfField
> -if( pAnnot->GetType() == ePdfAnnotation_Widget &&
> -pAnnot->GetObject()->GetDictionary().HasKey( PdfName("FT") ) )
> +if( pAnnot->GetType() == ePdfAnnotation_Widget )
> ++nCount;
> }
>
> @@ -570,8 +569,7 @@
> {
> pAnnot = this->GetAnnotation( i );
> // Count every widget annotation with a FieldType as PdfField
> -if( pAnnot->GetType() == ePdfAnnotation_Widget &&
> -pAnnot->GetObject()->GetDictionary().HasKey( PdfName("FT") ) )
> +if( pAnnot->GetType() == ePdfAnnotation_Widget )
> {
> if( nCount == index )
> {
>
>
>
> djenkins@ostara ~/src/podofo $ svn diff src/doc/PdfField.cpp
> Index: src/doc/PdfField.cpp
> ===
> --- src/doc/PdfField.cpp(revision 1597)
> +++ src/doc/PdfField.cpp(working copy)
> @@ -164,13 +164,31 @@
> PdfLocaleImbue(out);
> out << "podofo_field_" << m_pObject->Reference().ObjectNumber();
> }
> -
> PdfField::PdfField( PdfObject* pObject, PdfAnnotation* pWidget )
> : m_pObject( pObject ), m_pWidget( pWidget ), m_eField(
> ePdfField_Unknown )
> {
> +// ISO 32000:2008, Section 12.7.3.1, Table 220, Page #432.
>
> -PdfName fieldType = m_pObject->GetDictionary().GetKey( PdfName("FT")
> )->GetName();
> +const PdfObject *pFT = m_pObject->GetDictionary().GetKey(
> PdfName("FT") );
>
> +if (!pFT && m_pObject->GetDictionary().HasKey( PdfName ("Parent") ) )
> +{
> +const PdfObject *pTemp = m_pObject->GetIndirectKey ( PdfName
> ("Parent") );
> +if (!pTemp)
> +{
> +PODOFO_RAISE_ERROR (ePdfError_InvalidDataType);
> +}
> +
> +pFT = pTemp->GetDictionary().GetKey( PdfName ("FT") );
> +}
> +
> +if (!pFT)
> +{
> +PODOFO_RAISE_ERROR (ePdfError_NoObject);
> +}
> +
> +const PdfName fieldType = pFT->GetName();
> +
> if( fieldType == PdfName("Btn") )
> {
> PdfButton button( *this );
>
>
>
>
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] patch to implement form field inheritance (ISO 32000:2008, Section 12.7.3.1, table 220, page #432)
The following works for me. I can now access all of the fields on the
Arizona A1-QRT PDF form. I humbly submit this minor patch for peer-review
and hopeful inclusion into PoDoFo.
djenkins@ostara ~/src/podofo $ svn diff src/doc/PdfPage.cpp
Index: src/doc/PdfPage.cpp
===
--- src/doc/PdfPage.cpp (revision 1597)
+++ src/doc/PdfPage.cpp (working copy)
@@ -553,8 +553,7 @@
{
pAnnot = const_cast(this)->GetAnnotation( i );
// Count every widget annotation with a FieldType as PdfField
-if( pAnnot->GetType() == ePdfAnnotation_Widget &&
-pAnnot->GetObject()->GetDictionary().HasKey( PdfName("FT") ) )
+if( pAnnot->GetType() == ePdfAnnotation_Widget )
++nCount;
}
@@ -570,8 +569,7 @@
{
pAnnot = this->GetAnnotation( i );
// Count every widget annotation with a FieldType as PdfField
-if( pAnnot->GetType() == ePdfAnnotation_Widget &&
-pAnnot->GetObject()->GetDictionary().HasKey( PdfName("FT") ) )
+if( pAnnot->GetType() == ePdfAnnotation_Widget )
{
if( nCount == index )
{
djenkins@ostara ~/src/podofo $ svn diff src/doc/PdfField.cpp
Index: src/doc/PdfField.cpp
===
--- src/doc/PdfField.cpp(revision 1597)
+++ src/doc/PdfField.cpp(working copy)
@@ -164,13 +164,31 @@
PdfLocaleImbue(out);
out << "podofo_field_" << m_pObject->Reference().ObjectNumber();
}
-
PdfField::PdfField( PdfObject* pObject, PdfAnnotation* pWidget )
: m_pObject( pObject ), m_pWidget( pWidget ), m_eField(
ePdfField_Unknown )
{
+// ISO 32000:2008, Section 12.7.3.1, Table 220, Page #432.
-PdfName fieldType = m_pObject->GetDictionary().GetKey( PdfName("FT")
)->GetName();
+const PdfObject *pFT = m_pObject->GetDictionary().GetKey(
PdfName("FT") );
+if (!pFT && m_pObject->GetDictionary().HasKey( PdfName ("Parent") ) )
+{
+const PdfObject *pTemp = m_pObject->GetIndirectKey ( PdfName
("Parent") );
+if (!pTemp)
+{
+PODOFO_RAISE_ERROR (ePdfError_InvalidDataType);
+}
+
+pFT = pTemp->GetDictionary().GetKey( PdfName ("FT") );
+}
+
+if (!pFT)
+{
+PODOFO_RAISE_ERROR (ePdfError_NoObject);
+}
+
+const PdfName fieldType = pFT->GetName();
+
if( fieldType == PdfName("Btn") )
{
PdfButton button( *this );
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PDF Forms with non-standard annotations
On Fri, Apr 25, 2014 at 10:09 AM, Dennis Jenkins <
dennis.jenkins...@gmail.com> wrote:
>
> On Fri, Apr 25, 2014 at 6:56 AM, Leonard Rosenthol wrote:
>
>> The FT key can be inherited from it’s parent when they are organized in
>> a hierarchy (ISO 32000-1, 12.7.3.1).
>>
>> Yes, checking the Subtype is the correct way to identify a form field.
>> HOWEVER, you should probably also look at adding inheritance support (as a
>> generalization) to some/all of the field related APIs.
>>
>> Leonard
>>
>>
>>
Adjusting PoDoFo to handle the "inherited" fields in the A1-QRT form is not
going to be as easy as I had hoped. I tweaked PdfPage::GetNumFields() and
PdfPage::GetField() to ignore the check on the "FT" dictionary key.
"PdfPage::GetField()" now segfaults in the constructor to PdfField()
(PdfField.cpp, line #172) because 'GetKey('FT')' returns NULL, which is
passed as the 'this' pointer into 'GetName()'.
PdfField::PdfField( PdfObject* pObject, PdfAnnotation* pWidget )
: m_pObject( pObject ), m_pWidget( pWidget ), m_eField(
ePdfField_Unknown )
{
PdfName fieldType = m_pObject->GetDictionary().GetKey( PdfName("FT")
)->GetName();
if( fieldType == PdfName("Btn") )
{
PdfButton button( *this );
So, as Leonard pointed out, we will need to implement proper inheritance.
I see in PoDoFoBrowser that required dictionary keys are in the "->Parent"
dictionary of field 7 of page 0. The represents of the 'Parent' dictionary
as mentioned in the ISO document section 12.7.3.1, Table 220, page #432.
I'll take a stab at modifying PoDoFo to properly handle field inheritance.
I'll post something in the near future.
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PDF Forms with non-standard annotations
On Fri, Apr 25, 2014 at 6:56 AM, Leonard Rosenthol wrote:
> The FT key can be inherited from it’s parent when they are organized in
> a hierarchy (ISO 32000-1, 12.7.3.1).
>
> Yes, checking the Subtype is the correct way to identify a form field.
> HOWEVER, you should probably also look at adding inheritance support (as a
> generalization) to some/all of the field related APIs.
>
> Leonard
>
>
> 2) Should PoDoFo be changed to not require the presence of the "FT" key
> and simply accept the presence of the "/n Subtype = /Widget" to indicate a
> form field?
>
>
>
Leonard,
Thank you for your insightful feedback. I was going a bit nuts
wondering why the form worked in Adobe reader but lacked the keys. I did
not read the spec as closely as I should have.
Adding "inheritance support" is probably best left to Dominik and
others who are more familiar with the code base than I.
Dominik,
How do you want to tackle this issue? It is fairly easy to remove the
check for HasKey('FT') in PdfPage::GetNumFields() and PdfPage::GetField()...
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] PDF Forms with non-standard annotations
Hello, I am using PoDoFo in a project to fill-in a variety of US tax forms, such as the US Federal 941 form and the Arizona A1-QRT. I'm running into a problem with the A1-QRT form [1] using PoDoFo to access all of the form fields. According to PoDoFo, page #0 contains 26 form fields. However, the page/form actually has 34 fields. I dug into the code in PoDoFo for PdfPage::GetNumFields() and wrote a small program to dump all of the annotations for a given page of a pdf. The 34 annotations are all type "ePdfAnnotation_Widget", but only 26 has a dictionary key "FT", per the spec (ISO 32000:2008, section 12.7.3.1). The other 8 fields lack this dictionary key. Yet in "Adobe Reader XI", the form is fully functional and all 34 fields are operable. You can see the difference in PoDoFo-Browser. Annotations 0 through 6 all have an 'FT' key and are text fields. The next three are check boxes and lack the "FT" key. Of course, I can bypass "PdfPage::GetField()" and roll my own, but before doing so, I wanted to present my findings and ask: 1) How do these form fields work in Adobe Reader if they lack the "FT" key? 2) Should PoDoFo be changed to not require the presence of the "FT" key and simply accept the presence of the "/n Subtype = /Widget" to indicate a form field? Thank you for your time. [1] http://www.azdor.gov/Forms/Withholding.aspx -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] (bug?) doxygen docs for EPdfAlignment do not show enum values
http://podofo.sourceforge.net/doc/html/namespacePoDoFo.html#aa3dd4d46523fa75bcc52d09c035a25a9 Other enum data types show values (ex: EPdfColorSpace), but EPdfAlignment does not. I do not know if this was intentional. I have not audited any other enums - I just noticed this one when I wanted to know the exact spelling for "right" alignment. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] (BUG) PdfPainter::HorizontalLineTo() misspelled?
Hello, I think that the method "HorizontalLineTo" in the class "PdfPainter" is misspelled as "HorizonalLineTo" (the "t" is missing). At first I wondered if maybe the missing "t" was the difference between American English and some other language, but then I noticed that the doxygen notes suggest that the word should have been "Horizontal" (with the "t"). I apparently cannot open a bug report directly on sourceforge, despite being logged in, or I would have submitted that way. Thank you for your time, and your awesome PDF library. (Taken from podofo.sourceforge.net right now, "2014-04-13, ~00:00 CDT", but also present in v0.9.2) http://podofo.sourceforge.net/doc/html/classPoDoFo_1_1PdfPainter.html#ac0392ca65858ad395a6b63643086ce87 void PoDoFo::PdfPainter::HorizonalLineTo ( double dX ) Append a horizontal line to the current path Matches the SVG 'H' operator Parameters: dX x coordinate to draw the line to -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] rev 1443 breaks build with g++ 4.4.5 p1.2
Hello Dominik, I can confirm that rev 1447 compiles on my development server. Thank you for your hard work! On Sun, Mar 27, 2011 at 5:42 AM, Dominik Seichter wrote: > Hi Dennis, > > I could reproduce the problem on my other PC and I commited a fix to SVN. > > Regards, > Dom > > Am Wednesday 23 March 2011 schrieb dennis jenkins: >> Same error. Results of "svn up; make clean; make" are below. >> >> Maybe my glibc is out of date? My Gentoo system wants me to downgrade >> glibc. But the "emerge" keeps failing ona cryptic error. I will try >> to resolve this issue first. (I just noticed this, before I emailed >> the bug report to you). >> >> [ebuild UD] cross-i686-pc-linux-gnu/glibc-2.10.1-r1 [2.11.2-r3] >> USE="(multilib) nls -debug -gd -glibc-omitfp -hardened -profile >> (-selinux) -vanilla" 0 kB [?=>1] >> >> >> >> >> djenkins@ostara ~/code/podofo $ make >> [ 0%] Building CXX object >> src/CMakeFiles/podofo_static.dir/doc/PdfFontMetricsObject.cpp.o >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4/bits/stl_vector.h: >> In constructor >> 'PoDoFo::PdfFontMetricsObject::PdfFontMetricsObject(PoDoFo::PdfObject*, >> PoDoFo::PdfObject*, const PoDoFo::PdfEncoding*)': >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4/bits/stl_vector.h:552 >> : error: 'void std::vector<_Tp, _Alloc>::resize(size_t, _Tp) [with _Tp = >> PoDoFo::PdfObject, _Alloc = std::allocator]' is >> inaccessible >> /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:95: error: >> within this context >> /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:95: error: >> 'std::vector >' >> is not an accessible base of 'PoDoFo::PdfArray' >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4/bits/stl_vector.h:552 >> : error: 'void std::vector<_Tp, _Alloc>::resize(size_t, _Tp) [with _Tp = >> PoDoFo::PdfObject, _Alloc = std::allocator]' is >> inaccessible >> /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:105: >> error: within this context >> /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:105: >> error: 'std::vector> std::allocator >' is not an accessible base of >> 'PoDoFo::PdfArray' >> /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp: At global >> scope: /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:169: >> warning: unused parameter 'c' >> /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:175: >> warning: unused parameter 'nFirst' >> /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:175: >> warning: unused parameter 'nLast' >> /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:180: >> warning: unused parameter 'nGlyphId' >> /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:186: >> warning: unused parameter 'pszGlyphname' >> /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:192: >> warning: unused parameter 'lUnicode' >> make[2]: *** >> [src/CMakeFiles/podofo_static.dir/doc/PdfFontMetricsObject.cpp.o] Error 1 >> make[1]: *** [src/CMakeFiles/podofo_static.dir/all] Error 2 >> make: *** [all] Error 2 >> >> On Tue, Mar 22, 2011 at 5:31 PM, Dominik Seichter > wrote: >> > Hi Dennis, >> > >> > I am not sure what causes this problems, because the code looks good to >> > me and compiles for me using 4.4.4-1. >> > >> > I commited some fixes for compiler warnings and tried to address your >> > issues. Could you please try again with latest trunk? >> > >> > Regards, >> > Dom >> > >> > On Tuesday, March 22, 2011 09:49:33 pm dennis jenkins wrote: >> >> Hello Dominik, >> >> >> >> I think that a change introduced in rev 1443 into >> >> src/doc/PdfFontMetricsObject.cpp broke the build (at least on my >> >> Gentoo linux dev box). Gorey details below. >> >> >> >> >> >> djenkins@ostara ~/code/podofo $ g++ --version >> >> g++ (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5 >> >> Copyright (C) 2010 Free Software Foundation, Inc. >> >> This is free software; see the source for copying conditions. There is >> >> NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> >> PURPOSE. >> >> >> >> >> >> >> >> djenkins@ostara ~/code/podofo $ svn info
Re: [Podofo-users] rev 1443 breaks build with g++ 4.4.5 p1.2
Same error. Results of "svn up; make clean; make" are below. Maybe my glibc is out of date? My Gentoo system wants me to downgrade glibc. But the "emerge" keeps failing ona cryptic error. I will try to resolve this issue first. (I just noticed this, before I emailed the bug report to you). [ebuild UD] cross-i686-pc-linux-gnu/glibc-2.10.1-r1 [2.11.2-r3] USE="(multilib) nls -debug -gd -glibc-omitfp -hardened -profile (-selinux) -vanilla" 0 kB [?=>1] djenkins@ostara ~/code/podofo $ make [ 0%] Building CXX object src/CMakeFiles/podofo_static.dir/doc/PdfFontMetricsObject.cpp.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4/bits/stl_vector.h: In constructor 'PoDoFo::PdfFontMetricsObject::PdfFontMetricsObject(PoDoFo::PdfObject*, PoDoFo::PdfObject*, const PoDoFo::PdfEncoding*)': /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4/bits/stl_vector.h:552: error: 'void std::vector<_Tp, _Alloc>::resize(size_t, _Tp) [with _Tp = PoDoFo::PdfObject, _Alloc = std::allocator]' is inaccessible /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:95: error: within this context /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:95: error: 'std::vector >' is not an accessible base of 'PoDoFo::PdfArray' /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4/bits/stl_vector.h:552: error: 'void std::vector<_Tp, _Alloc>::resize(size_t, _Tp) [with _Tp = PoDoFo::PdfObject, _Alloc = std::allocator]' is inaccessible /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:105: error: within this context /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:105: error: 'std::vector >' is not an accessible base of 'PoDoFo::PdfArray' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp: At global scope: /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:169: warning: unused parameter 'c' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:175: warning: unused parameter 'nFirst' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:175: warning: unused parameter 'nLast' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:180: warning: unused parameter 'nGlyphId' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:186: warning: unused parameter 'pszGlyphname' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:192: warning: unused parameter 'lUnicode' make[2]: *** [src/CMakeFiles/podofo_static.dir/doc/PdfFontMetricsObject.cpp.o] Error 1 make[1]: *** [src/CMakeFiles/podofo_static.dir/all] Error 2 make: *** [all] Error 2 On Tue, Mar 22, 2011 at 5:31 PM, Dominik Seichter wrote: > Hi Dennis, > > I am not sure what causes this problems, because the code looks good to me and > compiles for me using 4.4.4-1. > > I commited some fixes for compiler warnings and tried to address your issues. > Could you please try again with latest trunk? > > Regards, > Dom > > On Tuesday, March 22, 2011 09:49:33 pm dennis jenkins wrote: >> Hello Dominik, >> >> I think that a change introduced in rev 1443 into >> src/doc/PdfFontMetricsObject.cpp broke the build (at least on my >> Gentoo linux dev box). Gorey details below. >> >> >> djenkins@ostara ~/code/podofo $ g++ --version >> g++ (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5 >> Copyright (C) 2010 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> >> >> djenkins@ostara ~/code/podofo $ svn info . >> Path: . >> URL: https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk >> Repository Root: https://podofo.svn.sourceforge.net/svnroot/podofo >> Repository UUID: f068efa2-cb12-0410-9b19-e61e8c05d287 >> Revision: 1442 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: domseichter >> Last Changed Rev: 1442 >> Last Changed Date: 2011-03-14 15:41:20 -0500 (Mon, 14 Mar 2011) >> >> >> djenkins@ostara ~/code/podofo $ make >> 100% successful, but with compiler warnings. >> >> >> djenkins@ostara ~/code/podofo $ svn up -r 1443 >> U src/doc/PdfFontMetricsObject.h >> U src/doc/PdfFontMetricsObject.cpp >> U src/doc/PdfFontCID.cpp >> U src/doc/PdfFontCache.cpp >> Updated to revision 1443. >> >> >> >> djenkins@ostara ~/code/podofo $ make >> Scanning dependencies of target podofo_static >> [ 0%] Building CXX object >> src/CMakeFiles/podofo_static.dir/doc/PdfFontCache.cpp.o >> [ 1%] Building CXX object >> src/CMakeFiles/podofo_static.dir/doc/PdfFon
[Podofo-users] rev 1443 breaks build with g++ 4.4.5 p1.2
Hello Dominik, I think that a change introduced in rev 1443 into src/doc/PdfFontMetricsObject.cpp broke the build (at least on my Gentoo linux dev box). Gorey details below. djenkins@ostara ~/code/podofo $ g++ --version g++ (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. djenkins@ostara ~/code/podofo $ svn info . Path: . URL: https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk Repository Root: https://podofo.svn.sourceforge.net/svnroot/podofo Repository UUID: f068efa2-cb12-0410-9b19-e61e8c05d287 Revision: 1442 Node Kind: directory Schedule: normal Last Changed Author: domseichter Last Changed Rev: 1442 Last Changed Date: 2011-03-14 15:41:20 -0500 (Mon, 14 Mar 2011) djenkins@ostara ~/code/podofo $ make 100% successful, but with compiler warnings. djenkins@ostara ~/code/podofo $ svn up -r 1443 Usrc/doc/PdfFontMetricsObject.h Usrc/doc/PdfFontMetricsObject.cpp Usrc/doc/PdfFontCID.cpp Usrc/doc/PdfFontCache.cpp Updated to revision 1443. djenkins@ostara ~/code/podofo $ make Scanning dependencies of target podofo_static [ 0%] Building CXX object src/CMakeFiles/podofo_static.dir/doc/PdfFontCache.cpp.o [ 1%] Building CXX object src/CMakeFiles/podofo_static.dir/doc/PdfFontCID.cpp.o /home/djenkins/code/podofo/src/doc/PdfFontCID.cpp:53: warning: unused parameter 'bEmbed' [ 1%] Building CXX object src/CMakeFiles/podofo_static.dir/doc/PdfFontFactory.cpp.o [ 1%] Building CXX object src/CMakeFiles/podofo_static.dir/doc/PdfFontMetricsObject.cpp.o /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp: In constructor 'PoDoFo::PdfFontMetricsObject::PdfFontMetricsObject(PoDoFo::PdfObject*, PoDoFo::PdfObject*, const PoDoFo::PdfEncoding*)': /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:94: warning: comparison between signed and unsigned integer expressions /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4/bits/stl_vector.h:552: error: 'void std::vector<_Tp, _Alloc>::resize(size_t, _Tp) [with _Tp = PoDoFo::PdfObject, _Alloc = std::allocator]' is inaccessible /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:95: error: within this context /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:95: error: 'std::vector >' is not an accessible base of 'PoDoFo::PdfArray' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:104: warning: comparison between signed and unsigned integer expressions /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/include/g++-v4/bits/stl_vector.h:552: error: 'void std::vector<_Tp, _Alloc>::resize(size_t, _Tp) [with _Tp = PoDoFo::PdfObject, _Alloc = std::allocator]' is inaccessible /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:105: error: within this context /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:105: error: 'std::vector >' is not an accessible base of 'PoDoFo::PdfArray' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp: In member function 'virtual double PoDoFo::PdfFontMetricsObject::CharWidth(unsigned char) const': /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:154: warning: comparison between signed and unsigned integer expressions /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp: At global scope: /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:169: warning: unused parameter 'c' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:175: warning: unused parameter 'nFirst' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:175: warning: unused parameter 'nLast' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:180: warning: unused parameter 'nGlyphId' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:186: warning: unused parameter 'pszGlyphname' /home/djenkins/code/podofo/src/doc/PdfFontMetricsObject.cpp:192: warning: unused parameter 'lUnicode' make[2]: *** [src/CMakeFiles/podofo_static.dir/doc/PdfFontMetricsObject.cpp.o] Error 1 make[1]: *** [src/CMakeFiles/podofo_static.dir/all] Error 2 make: *** [all] Error 2 Head rev (1444 at this time) has the same compiler error. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Major change in PoDoFo build: One library again
Your fix (rev 1429) now compiles and installs on my dev server. Thank you very much, Dominik! On Mon, Mar 7, 2011 at 4:23 PM, Dominik Seichter wrote: > Hi Dennis, > > This was exactly the problem! I had all headers lying around which caused the > problems. > > I commited necessary forward headers to SVN, which should fix your problem. > > Thanks for reporting! > > Regards, > Dom > > On Monday, March 07, 2011 01:52:42 am dennis jenkins wrote: >> Dominik, I just had a thought. When I'm building podofo, I'm >> doing it on a linux box that does NOT already have it installed. >> "/usr/local/include" lacks any podofo headers. Maybe its working on >> your server because g++ is finding your installed headers and not >> failing to (mis)find the shipped ones. >> >> ?? >> >> On Sun, Mar 6, 2011 at 6:27 PM, dennis jenkins >> >> wrote: >> > [ 31%] Building CXX object >> > src/CMakeFiles/podofo_static.dir/base/PdfXRefStreamParserObject.cpp.o >> > cd /home/djenkins/code/podofo/src && /usr/bin/c++ >> > -I/home/djenkins/code/podofo -I/home/djenkins/code/podofo/src >> > -I/usr/include/freetype2 -std=c++98 -Wall -Woverloaded-virtual >> > -Wswitch-enum -Wcast-qual -Wwrite-strings -Wredundant-decls -Wreorder >> > -Wold-style-cast -W -DBUILDING_PODOFO -o >> > CMakeFiles/podofo_static.dir/base/PdfXRefStreamParserObject.cpp.o -c >> > /home/djenkins/code/podofo/src/base/PdfXRefStreamParserObject.cpp >> > /usr/bin/cmake -E cmake_progress_report >> > /home/djenkins/code/podofo/CMakeFiles [ 31%] Building CXX object >> > src/CMakeFiles/podofo_static.dir/doc/PdfAcroForm.cpp.o >> > cd /home/djenkins/code/podofo/src && /usr/bin/c++ >> > -I/home/djenkins/code/podofo -I/home/djenkins/code/podofo/src >> > -I/usr/include/freetype2 -std=c++98 -Wall -Woverloaded-virtual >> > -Wswitch-enum -Wcast-qual -Wwrite-strings -Wredundant-decls -Wreorder >> > -Wold-style-cast -W -DBUILDING_PODOFO -o >> > CMakeFiles/podofo_static.dir/doc/PdfAcroForm.cpp.o -c >> > /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp >> > In file included from >> > /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:21: >> > /home/djenkins/code/podofo/src/doc/PdfAcroForm.h:24:36: error: >> > podofo/base/PdfDefines.h: No such file or directory >> > In file included from >> > /home/djenkins/code/podofo/src/doc/PdfAcroForm.h:25, from >> > /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:21: >> > /home/djenkins/code/podofo/src/doc/PdfElement.h:25:35: error: >> > podofo/base/PdfObject.h: No such file or directory >> > In file included from >> > /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:27: >> > /home/djenkins/code/podofo/src/doc/PdfDocument.h:27:35: error: >> > podofo/base/PdfParser.h: No such file or directory >> > /home/djenkins/code/podofo/src/doc/PdfDocument.h:28:35: error: >> > podofo/base/PdfWriter.h: No such file or directory >> > In file included from >> > /home/djenkins/code/podofo/src/doc/PdfDocument.h:31, from >> > /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:27: >> > >> > >> > (many more errors omitted). >> > >> > Some research: >> > djenkins@ostara ~/code/podofo $ find . -name "PdfDefines.h" >> > ./src/base/PdfDefines.h >> > >> > Its looking in "podofo/base", but the header is really in "src/base". >> > >> > On Sun, Mar 6, 2011 at 3:44 PM, Dominik Seichter > wrote: >> >> Hi Dennis, >> >> >> >> Hmm, it compiles for me. >> >> >> >> Can you please send the output of "VERBOSE=1 make" ? >> >> Seems like I messed up something with the include directories ... >> >> >> >> Thanks, >> >> Dominik >> >> >> >> On Sunday, March 06, 2011 09:58:27 pm dennis jenkins wrote: >> >>> Hello Dominik, >> >>> >> >>> On my up-to-date Gentoo dev box, I am unable to compile the latest >> >>> SVN checkout of podofo (svn v 1427). I can reproduce as follows: >> >>> >> >>> $ rm -rf podofo >> >>> $ svn co https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk >> >>> podofo $ cd podofo >> >>> $ svn info . # shows version 1427 >> >>> $ cmake -G "Unix Makefiles" >> >>> $ make >> >>> >> >>> The compile
Re: [Podofo-users] Major change in PoDoFo build: One library again
Dominik, I just had a thought. When I'm building podofo, I'm doing it on a linux box that does NOT already have it installed. "/usr/local/include" lacks any podofo headers. Maybe its working on your server because g++ is finding your installed headers and not failing to (mis)find the shipped ones. ?? On Sun, Mar 6, 2011 at 6:27 PM, dennis jenkins wrote: > [ 31%] Building CXX object > src/CMakeFiles/podofo_static.dir/base/PdfXRefStreamParserObject.cpp.o > cd /home/djenkins/code/podofo/src && /usr/bin/c++ > -I/home/djenkins/code/podofo -I/home/djenkins/code/podofo/src > -I/usr/include/freetype2 -std=c++98 -Wall -Woverloaded-virtual > -Wswitch-enum -Wcast-qual -Wwrite-strings -Wredundant-decls -Wreorder > -Wold-style-cast -W -DBUILDING_PODOFO -o > CMakeFiles/podofo_static.dir/base/PdfXRefStreamParserObject.cpp.o -c > /home/djenkins/code/podofo/src/base/PdfXRefStreamParserObject.cpp > /usr/bin/cmake -E cmake_progress_report /home/djenkins/code/podofo/CMakeFiles > [ 31%] Building CXX object > src/CMakeFiles/podofo_static.dir/doc/PdfAcroForm.cpp.o > cd /home/djenkins/code/podofo/src && /usr/bin/c++ > -I/home/djenkins/code/podofo -I/home/djenkins/code/podofo/src > -I/usr/include/freetype2 -std=c++98 -Wall -Woverloaded-virtual > -Wswitch-enum -Wcast-qual -Wwrite-strings -Wredundant-decls -Wreorder > -Wold-style-cast -W -DBUILDING_PODOFO -o > CMakeFiles/podofo_static.dir/doc/PdfAcroForm.cpp.o -c > /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp > In file included from /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:21: > /home/djenkins/code/podofo/src/doc/PdfAcroForm.h:24:36: error: > podofo/base/PdfDefines.h: No such file or directory > In file included from /home/djenkins/code/podofo/src/doc/PdfAcroForm.h:25, > from /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:21: > /home/djenkins/code/podofo/src/doc/PdfElement.h:25:35: error: > podofo/base/PdfObject.h: No such file or directory > In file included from /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:27: > /home/djenkins/code/podofo/src/doc/PdfDocument.h:27:35: error: > podofo/base/PdfParser.h: No such file or directory > /home/djenkins/code/podofo/src/doc/PdfDocument.h:28:35: error: > podofo/base/PdfWriter.h: No such file or directory > In file included from /home/djenkins/code/podofo/src/doc/PdfDocument.h:31, > from /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:27: > > > (many more errors omitted). > > Some research: > djenkins@ostara ~/code/podofo $ find . -name "PdfDefines.h" > ./src/base/PdfDefines.h > > Its looking in "podofo/base", but the header is really in "src/base". > > > > > > On Sun, Mar 6, 2011 at 3:44 PM, Dominik Seichter wrote: >> Hi Dennis, >> >> Hmm, it compiles for me. >> >> Can you please send the output of "VERBOSE=1 make" ? >> Seems like I messed up something with the include directories ... >> >> Thanks, >> Dominik >> >> On Sunday, March 06, 2011 09:58:27 pm dennis jenkins wrote: >>> Hello Dominik, >>> >>> On my up-to-date Gentoo dev box, I am unable to compile the latest >>> SVN checkout of podofo (svn v 1427). I can reproduce as follows: >>> >>> $ rm -rf podofo >>> $ svn co https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk >>> podofo $ cd podofo >>> $ svn info . # shows version 1427 >>> $ cmake -G "Unix Makefiles" >>> $ make >>> >>> The compile dies here: >>> >>> In file included from >>> /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:21: >>> /home/djenkins/code/podofo/src/doc/PdfAcroForm.h:24:36: error: >>> podofo/base/PdfDefines.h: No such file or directory >>> >>> >>> (lots more errors omitted). Hopefully this is enough info for you to >>> reproduce, or tell me what I've done incorrectly. Thank you for your >>> time. >>> >>> On Sun, Mar 6, 2011 at 12:11 PM, Dominik Seichter >> wrote: >>> > Hi, >>> > >>> > I changed the build system so that only one library is build again. This >>> > reverts the previous change where PoDoFo was split into two libraries >>> > podofo- base and podofo-doc. Now, there is only one library libpodofo or >>> > podofo.dll. >>> > >>> > I reverted the change because of major linkage problems, which caused for >>> > example crashes in PdfMemDocument. This and other reasons kept many >>> > people from switching to trunk and to the late
Re: [Podofo-users] Major change in PoDoFo build: One library again
[ 31%] Building CXX object src/CMakeFiles/podofo_static.dir/base/PdfXRefStreamParserObject.cpp.o cd /home/djenkins/code/podofo/src && /usr/bin/c++ -I/home/djenkins/code/podofo -I/home/djenkins/code/podofo/src -I/usr/include/freetype2 -std=c++98 -Wall -Woverloaded-virtual -Wswitch-enum -Wcast-qual -Wwrite-strings -Wredundant-decls -Wreorder -Wold-style-cast -W -DBUILDING_PODOFO -o CMakeFiles/podofo_static.dir/base/PdfXRefStreamParserObject.cpp.o -c /home/djenkins/code/podofo/src/base/PdfXRefStreamParserObject.cpp /usr/bin/cmake -E cmake_progress_report /home/djenkins/code/podofo/CMakeFiles [ 31%] Building CXX object src/CMakeFiles/podofo_static.dir/doc/PdfAcroForm.cpp.o cd /home/djenkins/code/podofo/src && /usr/bin/c++ -I/home/djenkins/code/podofo -I/home/djenkins/code/podofo/src -I/usr/include/freetype2 -std=c++98 -Wall -Woverloaded-virtual -Wswitch-enum -Wcast-qual -Wwrite-strings -Wredundant-decls -Wreorder -Wold-style-cast -W -DBUILDING_PODOFO -o CMakeFiles/podofo_static.dir/doc/PdfAcroForm.cpp.o -c /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp In file included from /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:21: /home/djenkins/code/podofo/src/doc/PdfAcroForm.h:24:36: error: podofo/base/PdfDefines.h: No such file or directory In file included from /home/djenkins/code/podofo/src/doc/PdfAcroForm.h:25, from /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:21: /home/djenkins/code/podofo/src/doc/PdfElement.h:25:35: error: podofo/base/PdfObject.h: No such file or directory In file included from /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:27: /home/djenkins/code/podofo/src/doc/PdfDocument.h:27:35: error: podofo/base/PdfParser.h: No such file or directory /home/djenkins/code/podofo/src/doc/PdfDocument.h:28:35: error: podofo/base/PdfWriter.h: No such file or directory In file included from /home/djenkins/code/podofo/src/doc/PdfDocument.h:31, from /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:27: (many more errors omitted). Some research: djenkins@ostara ~/code/podofo $ find . -name "PdfDefines.h" ./src/base/PdfDefines.h Its looking in "podofo/base", but the header is really in "src/base". On Sun, Mar 6, 2011 at 3:44 PM, Dominik Seichter wrote: > Hi Dennis, > > Hmm, it compiles for me. > > Can you please send the output of "VERBOSE=1 make" ? > Seems like I messed up something with the include directories ... > > Thanks, > Dominik > > On Sunday, March 06, 2011 09:58:27 pm dennis jenkins wrote: >> Hello Dominik, >> >> On my up-to-date Gentoo dev box, I am unable to compile the latest >> SVN checkout of podofo (svn v 1427). I can reproduce as follows: >> >> $ rm -rf podofo >> $ svn co https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk >> podofo $ cd podofo >> $ svn info . # shows version 1427 >> $ cmake -G "Unix Makefiles" >> $ make >> >> The compile dies here: >> >> In file included from >> /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:21: >> /home/djenkins/code/podofo/src/doc/PdfAcroForm.h:24:36: error: >> podofo/base/PdfDefines.h: No such file or directory >> >> >> (lots more errors omitted). Hopefully this is enough info for you to >> reproduce, or tell me what I've done incorrectly. Thank you for your >> time. >> >> On Sun, Mar 6, 2011 at 12:11 PM, Dominik Seichter > wrote: >> > Hi, >> > >> > I changed the build system so that only one library is build again. This >> > reverts the previous change where PoDoFo was split into two libraries >> > podofo- base and podofo-doc. Now, there is only one library libpodofo or >> > podofo.dll. >> > >> > I reverted the change because of major linkage problems, which caused for >> > example crashes in PdfMemDocument. This and other reasons kept many >> > people from switching to trunk and to the latest version of PoDoFo. >> > These problem should all be gone and if you refused to upgrade, it should >> > be safe now. >> > >> > This is the basis for the upcoming PoDoFo 0.9.0 release, which I intend >> > to release next week. >> > >> > Please report any probles you encounter due to this change! >> > >> > Regards, >> > Dom >> > >> > -- >> > Dominik Seichter - domseich...@web.de - http://domseichter.blogspot.com >> > KRename - http://www.krename.net - Powerful batch renamer for KDE >> > KBarcode - http://www.kbarcode.net - Barcode and label printing >> > PoDoFo - http://podofo.sf.net - PDF generation and parsing library >> > >> >
Re: [Podofo-users] Major change in PoDoFo build: One library again
Hello Dominik, On my up-to-date Gentoo dev box, I am unable to compile the latest SVN checkout of podofo (svn v 1427). I can reproduce as follows: $ rm -rf podofo $ svn co https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk podofo $ cd podofo $ svn info . # shows version 1427 $ cmake -G "Unix Makefiles" $ make The compile dies here: In file included from /home/djenkins/code/podofo/src/doc/PdfAcroForm.cpp:21: /home/djenkins/code/podofo/src/doc/PdfAcroForm.h:24:36: error: podofo/base/PdfDefines.h: No such file or directory (lots more errors omitted). Hopefully this is enough info for you to reproduce, or tell me what I've done incorrectly. Thank you for your time. On Sun, Mar 6, 2011 at 12:11 PM, Dominik Seichter wrote: > Hi, > > I changed the build system so that only one library is build again. This > reverts the previous change where PoDoFo was split into two libraries podofo- > base and podofo-doc. Now, there is only one library libpodofo or podofo.dll. > > I reverted the change because of major linkage problems, which caused for > example crashes in PdfMemDocument. This and other reasons kept many people > from switching to trunk and to the latest version of PoDoFo. > These problem should all be gone and if you refused to upgrade, it should be > safe now. > > This is the basis for the upcoming PoDoFo 0.9.0 release, which I intend to > release next week. > > Please report any probles you encounter due to this change! > > Regards, > Dom > > -- > Dominik Seichter - domseich...@web.de - http://domseichter.blogspot.com > KRename - http://www.krename.net - Powerful batch renamer for KDE > KBarcode - http://www.kbarcode.net - Barcode and label printing > PoDoFo - http://podofo.sf.net - PDF generation and parsing library > > -- > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > > -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] PODOFO_VERBOSE_DEBUG
I was curious about the same thing - and I would like the symbol undefined. I use "svn" to maintain a PoDoFo source tree on my own system for this exact reason. My personal copy of the source tree has this symbol undefined. When Dominick mentions that he has committed changes to the repository I just do "svn up; make install". So far this has worked for me, but I do wonder why the symbol is defined... and has been since svn r882 (2008-08-01, 10:41:42 -0500) svn diff -r 881:882 https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk/src/PdfParser.cpp I think that it would be nice if it were possibly to insert a "hook" into PoDoFo's logging system so that PdfError::Message would invoke a user (eg, me) supplied callback instead of just emitting to STDERR. I would like to pre-pend my own error info to the error text and then write the entire even to my own log file (that my app already has opened). I have no had time / requirements to do this yet, but I probably will at some point in the future. On Mon, Sep 6, 2010 at 4:39 PM, Radu Braniste wrote: > In PdfParser, line 49 there is this define: > #define PODOFO_VERBOSE_DEBUG > Any reason to have it there? Is at least annoying to have in production code > a bunch of debug lines every time this class is used > Thanks > Radu > -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] g++example
g++ fileJ.cpp -o exename -lpodofo ./exename On Mon, Aug 16, 2010 at 12:03 PM, necko necko wrote: > Hello, > I have trouble using PoDoFo. The example I tried to copy/paste and compile > is helloworld.cpp, the content of which is copied to fileJ.cpp. > Now, I do not know what command to call (g++ something) to have this > working. > Perhaps you could help. I would really appreciate that. > Thanks > > > -- > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > > -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] message "Demand loading on, but can't demand-load from object stream"
On Thu, May 13, 2010 at 4:09 AM, Dominik Seichter < domseich...@googlemail.com> wrote: > Am Donnerstag 13 Mai 2010 schrieb shoks: > > I overlooked the restrictions on the PDF form. After removing the > > restrictions, I was able to fill up the form. I think the library should > > throw an exception or something visible when there are restrictions in > the > > PDF form. > > Could you provide a patch for this? > I accidentally did a "reply" and sent this to Dominik when I meant to post it to the mailing list for all to see and discuss. Just a thought... Would implementing such logic artificially restrict what one could do to a PDF? It seems to me that podofo is about low-level manipulation of a PDF - anything that produces a syntactically valid PDF (as seen by an arbitrary third party PDF parsing engine) should be fair game. Implementing the proposed logic would prevent that. Granted, I don't have a use case where I would NOT want this patch. May I suggest something slightly different: 1) Implement the above logic, but make it possible to enable and disable at run-time. 2) Instead of throwing an exception (and presumably preventing the changes for taking effect), create two methods: 2a) One to determine if the form has "editing restrictions". 2b) One to create or remove "editing restrictions". (ps- Does this violate any part of the PDF specification license agreement??) Just my humble opinion. ps- Podofo rocks! -- ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] message "Demand loading on, but can't demand-load from object stream"
On Wed, May 12, 2010 at 3:09 AM, shoks wrote:
> Hi,
>
> Thanks for your response and the code. Unfortunately, it doesn't work with
> the PDF that I created using Adobe LiveCycle ES 2 (on Windows Vista). If
> viewed using Acrobat, the field is empty or unchanged. But with FormTest,
> the text field is updated. I tried your form (f941.pdf) and the fields are
> also updated. Could this be a font issue? I noticed that the font used in
> the PDF file is LucidaSans (Type: TrueType, Encoding:Ansi, Actual Font:
> Adobe Sans MM, Actual Font Type: Type 1). Should this be "Arial" or similar
> to the value in doc.CreateFont ("Arial")?
>
>
Unfortunately, I don't know. I'm a PDF novice. I just need to fill out a
few US government tax forms, and since those work for me, I was a happy
camper :)
Are you able to post a sample PDF (on a web site, and drop a link here)?
Maybe it would be helpful to compare the internal structure of a PDF that
can be filled in with yours using the "podofo browser".
--
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] message "Demand loading on, but can't demand-load from object stream"
Hello,
Just ignore the "Deman loading..." stuff (I commented out that code in
my own copy of podofo).
I had the same problem a few months ago. I needed to fill out a form
and have my changes "visible" inside Adobe Reader. A few helpful
individuals on this list provided me with the information that I needed. I
ended up implementing this function, which I call before filling in the
individual form text fields. I won't claim that my solution is the "correct
solution", but it works for me.
// See section 12.7.3.3 (page 434) of ISO-32000-1:2008.
// Need to construct an appearance stream for each form field,
// or configure document to generated one dynamically.
// See section 12.7.4.3 (page 444) of ISO-32000-1:2008.
// Shows a correct "Appearance Stream" for a text field.
// We can always directly hack the dictionary thuslu:
//PdfAnnotation::GetObject()->GetDictionary()
static void HackPdfFormDocument (PdfDocument &doc)
{
//
http://www.mail-archive.com/podofo-users@lists.sourceforge.net/msg01155.html
// Stolen from PdfAcroForm::Init()
// doc.GetAcroForm()->Init
(PdfAcroForm::ePdfAcroFormDefaultAppearance_BlackText12pt);
PdfObject *pObj = doc.GetAcroForm()->GetObject();
pObj->GetDictionary().AddKey (PdfName ("NeedAppearances"),
PdfVariant (true));
if (!pObj->GetDictionary().HasKey("DA"))
{
PdfFont *pFont = doc.CreateFont ("Arial");
PdfObject *pResource = NULL;
PdfObject *pFontDict = NULL;
// Create "DR" key.
if (!pObj->GetDictionary().HasKey (PdfName ("DR")))
{
pObj->GetDictionary().AddKey (PdfName ("DR"),
PdfDictionary());
}
pResource = pObj->GetDictionary().GetKey( PdfName("DR") );
if (!pResource->GetDictionary().HasKey( PdfName ("Font")))
{
pResource->GetDictionary().AddKey (PdfName ("Font"),
PdfDictionary());
}
pFontDict = pResource->GetDictionary().GetKey(
PdfName("Font") );
pFontDict->GetDictionary().AddKey( pFont->GetIdentifier(),
pFont->GetObject()->Reference() );
// Create "DA" key.
std::ostringstream oss;
PdfLocaleImbue (oss);
oss << "0 0 0 rg /" << pFont->GetIdentifier().GetName() << "
12 Tf";
pObj->GetDictionary().AddKey( PdfName("DA"), PdfString(
oss.str() ) );
}
}
On Tue, May 11, 2010 at 12:55 AM, shoks wrote:
> What does it mean?
>
> I've tried running FormTest to fill-up a form that contains a text and
> textfield. The form was created using Adobe Livecycle ES2. Was able to enter
> the value for the textfield but the output PDF, the field is still empty. Is
> this a known limitation? Am I missing something? I can email the form if it
> would help.
>
> ---
>
> s...@shovm:~/work/webprint/podofo/latest/svn-051110/podofo-build/test/FormTest$
> ./FormTest basicform1.pdf out.pdf
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> Demand loading on, but can't demand-load from object stream.
> <<
> /Type /XRef
> /DecodeParms <<
> /Columns 4
> /Predictor 12Attached is the PDF form.
> >>
> /Filter /FlateDecode
> /ID [ <587040659ED7434A94715F5497439722>
> ]
> /Index [ 34 21 ]
> /Info 33
Re: [Podofo-users] Adobe built-in Base14 fonts, font metrics and font cache methods
On Mon, May 3, 2010 at 5:32 PM, Dominik Seichter wrote: > Hi Dennis, > > I am sorry for breaking the build! I added the two missing headers to > CMakeLists.txt. The build should be working again, now. > > Kindest regards, >Dom > No need to apologize. Thank you for the quick fix. In the mean time I had manually copied the header file. When I retested after your commit I fully removed podofo first. I can confirm that it fixes the build for me. Thank you very much. -- ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Adobe built-in Base14 fonts, font metrics and font cache methods
Hello.
I think that Dominik Seichter's merging of this fix has broken "make
install". Until this morning I had a local copy of SVN #1202 (with some
minor private changes). One on of my development machines I did an "svn
up", which brought me to version #1227. I then did a "make clean && make
uninstall && make install". "Make install" appears to NOT install
"PdfFontMetricsBase14.h" into "/usr/local/include/podofo" as I would expect
it to. This causes my own application to fail to compile:
djenk...@djenkins-vm ~/code/capybara $ make all
g++ --std=c++0x -ggdb -O2 -Wall -Wno-write-strings -fPIC -I./
-I/usr/include/openssl -DDEBUG -D_GNU_SOURCE -D__SVN_REVISION__=\"481\"
-I/usr/include/postgresql-8.3 -I/usr/include/uuid -I/usr/include/freetype2
-fpch-preprocess -c lib/common.h -o lib/common.h.gch
In file included from /usr/local/include/podofo/PdfFont.h:28,
from /usr/local/include/podofo/PdfFontCache.h:28,
from /usr/local/include/podofo/PdfDocument.h:26,
from /usr/local/include/podofo/podofo.h:49,
from lib/common.h:38:
/usr/local/include/podofo/PdfFontMetrics.h:26:34: error:
PdfFontMetricsBase14.h: No such file or directory
### From my private podofo revision directory:
djenk...@djenkins-vm ~/code/podofo $ find /usr/local/include/podofo . -name
PdfFont.h -o -name PdfFontMetricsBase14.h
/usr/local/include/podofo/PdfFont.h
./src/PdfFont.h
./src/PdfFontMetricsBase14.h
djenk...@djenkins-vm ~/code/podofo $ svn info .
Path: .
URL: https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk
Repository Root: https://podofo.svn.sourceforge.net/svnroot/podofo
Repository UUID: f068efa2-cb12-0410-9b19-e61e8c05d287
Revision: 1227
Node Kind: directory
Schedule: normal
Last Changed Author: domseichter
Last Changed Rev: 1227
Last Changed Date: 2010-05-02 05:53:37 -0500 (Sun, 02 May 2010)
And, my private changes (just to rule them out):
djenk...@djenkins-vm ~/code/podofo $ svn diff
Index: src/PdfParser.cpp
===
--- src/PdfParser.cpp (revision 1227)
+++ src/PdfParser.cpp (working copy)
@@ -46,7 +46,7 @@
#define PDF_XREF_ENTRY_SIZE 20
#define PDF_XREF_BUF512
-#define PODOFO_VERBOSE_DEBUG
+//#define PODOFO_VERBOSE_DEBUG
namespace PoDoFo {
On Sun, May 2, 2010 at 10:03 AM, Ian Curington wrote:
> As there was no reply to the previous message on this topic, we
> have gone ahead and implemented support for Base14 built-in fonts
> and contributed the new features to the library.
> Thank you very much to Dominik for cleanup, name changes and merging
> into SVN.
>
> This has been tested on Win32 VS2005, VS2008 32-bit, Vista x64,
> and GCC linux x64.
>
> The support for Base14 is automatic, that is, if you ask for a font name
> matching one of the Base14 names, it gets used. There is no special
> flag or mode switch required.
>
> The current design choice is to always use Base14 if available even if
> some external system font (to be embedded) was available with the same
> name, as file size and efficiency is rated higher than
> matching an exact font in minute detail. If this is not want you
> want, I'm sure the code can easily be patched.
>
> There is a small remaining issue that font metrics return zero for
> height on symbols and zingbats, but at least it gets the width right.
> (contributions welcome!)
>
> Note also the new test case, a simple enhancement to
> HelloWorld to use the new fonts. The new example can be found in
> examples\helloworld-base14.
>
> --
> -- Ian Curington -- i...@acm.org ---
>
>
> --
> ___
> 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] Difficulty populating PDF Form text fields
> > So, my question now is what is a "proper" fix? I can think of a few > alternatives: > > 1) Wait for PoDoFo to make a formal code change that helps my situation. > > 2) Continue to use a hacked PoDoFo (not a problem right now, but not > desirable long term). > > 3) Extract the relevant logic from PdfAcroInit() and embed it directly > in my own code (risking my code breaking in the future if PoDoFo makes > an incompatible change). I have not fully researched this > alternative. At this time I don't know if the methods invoked by > PdfAcroRead::Init() are "public" such that I can invoke them myself > directly in my own code. I have successfully implemented option #3. However, if this is not he best long-term approach, please let us know. Thanks! -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Difficulty populating PDF Form text fields
On Tue, Mar 23, 2010 at 2:31 PM, dennis jenkins wrote: > Dominik, > > Thank you for that suggestion. The code change fixes PDFs that I > generate myself (my small test case). > However, it does not work with editing existing PDFs. > > I will study the functionality in PdfAcroForm.cpp and experiment. > Thank you very much. > > ps- Why is the "NeedAppearances" code commented out at all? In a > future release will there a way to specify this behavior > programatically so that users won't need to maintain custom PoDoFos? I got it to work, with a little C++ abuse. I modified "PdfAcroForm.h" so that "Init()" was a public method, recompiled and re-installed. In my own code, I load the IRS form into a PdfMemDocument, then do this: doc.GetAcroForm()->Init (PdfAcroForm::ePdfAcroFormDefaultAppearance_BlackText12pt); I then loop through all of the form fields, calling "SetText" on the text fields. Finally I save the PDF. The resulting PDF displays as desired. So, my question now is what is a "proper" fix? I can think of a few alternatives: 1) Wait for PoDoFo to make a formal code change that helps my situation. 2) Continue to use a hacked PoDoFo (not a problem right now, but not desirable long term). 3) Extract the relevant logic from PdfAcroInit() and embed it directly in my own code (risking my code breaking in the future if PoDoFo makes an incompatible change). I have not fully researched this alternative. At this time I don't know if the methods invoked by PdfAcroRead::Init() are "public" such that I can invoke them myself directly in my own code. Anyway, thank you guys very much for your assistance. If you are willing to make a change to PoDoFo to make the above "proper" or "formal" or whatever then I would be more than happy to test. Thank you for your time. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] Difficulty populating PDF Form text fields
Dominik,
Thank you for that suggestion. The code change fixes PDFs that I
generate myself (my small test case).
However, it does not work with editing existing PDFs.
I will study the functionality in PdfAcroForm.cpp and experiment.
Thank you very much.
ps- Why is the "NeedAppearances" code commented out at all? In a
future release will there a way to specify this behavior
programatically so that users won't need to maintain custom PoDoFos?
On Sun, Mar 21, 2010 at 5:36 PM, Dominik Seichter wrote:
> Hi,
>
> Thanks for your very good problem description.
>
> Please try to enable the line below in PdfAcroForm::Init ():
>
> m_pObject->GetDictionary().AddKey( PdfName("NeedAppearances"),
> PdfVariant(true) );
>
> Enabling this line should fix your problem.
>
> Best regards,
> Dom
>
>
> Am Dienstag 16 März 2010 schrieb dennis jenkins:
>> Hello PoDoFo Community,
>>
>> I am having difficulty understanding why PDF forms created and
>> populated with podofo do not work in Adobe Reader as desired. I wrote
>> code to create a one page PDF with one form field and set text on it.
>> The text is clearly in the form (when viewed with PoDoFoBrowser 0.5
>> (win32)). Yet when I open the PDF in Adobe Reader (9.2.0, win32), the
>> field appears empty. When I click on the text field my value is
>> visible. When I click off of the field, my value disappears. (My
>> code is below)
>>
>> I'm using the latest podofo from svn (rev 1199, checked out this
>> morning), and the PDF 1.3 spec from Adobe's web site [1]. I studied
>> the sample code in "podofo/test/FormTest" [2]. I skimmed most of the
>> PDF reference manual, and intently read (twice) section 7.6,
>> "Interactive Forms".
>>
>> My ultimate goal is to write a routine that will read a third
>> party PDF (with a form on it), fill in the fields and save the form.
>> At a later time a user would then load the form into and further edit
>> it, email it and/or print it. When I failed to get this to work with
>> the desired forms (US / IRS tax form "941" [3]), I created a small app
>> to build a custom PDF with a simplified form. I get the same results
>> with both forms.
>>
>> I've viewed both forms inside PoDoFoBrowser. Some annotation
>> elements have different attributes, but they are essentially the same.
>>
>> I have three theories:
>>
>> a) It is simply not possible to construct a PDF form with data
>> pre-populated using "PdfTextField.SetText()".
>>
>> b) I'm doing something wrong.
>>
>> c) I need to set some additional attributes or values in the
>> annotation element, or its parent object, or in the document object
>> itself.
>>
>> At this time I can see only one possible hack: To read the form
>> field's "rects" and create a text overlay in the same position. This
>> is indeed a hack as this will prevent the user from properly editing
>> the form at a later time (prior to them printing or otherwise using
>> it).
>>
>> Although I am using PoDoFoBrowser and Adobe Reader on win32, I am
>> doing my development on Gentoo Linux. This, hopefully, does not
>> matter.
>>
>> I would very much appreciate any suggestions, assistance, etc...
>> If it would be helpful, I can post the "stuff" that PoDoFoBrowser
>> shows inside the forms. However, it is fairly easy to download the
>> "941" form and view it directly.
>>
>> Thank you for your time.
>>
>>
>> [1] http://www.adobe.com/devnet/pdf/pdfs/PDFReference13.pdf
>>
>> [2]
>> https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk/test/FormTe
>> st/FormTest.cpp
>>
>> [3] http://www.irs.gov/pub/irs-pdf/f941.pdf
>>
>>
>>
>> // "main()", "#include" and original error handling omitted for brevity.
>> // "HelloWorld" line shamelessly stolen from the PoDoFo online example.
>>
>> void RunPdfTest (const char *filename)
>> {
>> PdfStreamedDocument doc (filename);
>> PdfPage *pPage = doc.CreatePage (PdfPage::CreateStandardPageSize
>> (ePdfPageSize_Letter));
>>
>> PdfPainter painter;
>> painter.SetPage (pPage);
>> PdfFont *pFont = doc.CreateFont ("Arial");
>> pFont->SetFontSize (18.0);
>> painter.SetFont (pFont);
>> painter.DrawText (56.69, pPage->GetPageSize().GetHeight() - 56.69,
>> "Hello World!" );
[Podofo-users] "Yes" vs "On" in PdfAnnotations
Section 12.7.4.2.3 of the ISO-32000-1:2008 [1] document states that the appearance stream dictionary for check boxes should use the names "Off" and "Yes". In PoDoFo (svn rev 1199), "src/PdfAnnotation.cpp", lines #121 and #127 use "Off" and "On". [2] I am a beginning novice in PDF internals, so I make no claim that PoDoFo is "incorrect". I just noticed this discrepancy between the spec and the implementation while researching an annotation problem. I thought that PoDoFo might be incorrect, so I edited my copy to use "Yes" instead of "On". Unfortunately, that did not solve my problem. [1] http://www.adobe.com/devnet/acrobat/pdfs/PDF32000_2008.pdf [2] https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk/src/PdfAnnotation.cpp -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Difficulty populating PDF Form text fields
Hello PoDoFo Community,
I am having difficulty understanding why PDF forms created and
populated with podofo do not work in Adobe Reader as desired. I wrote
code to create a one page PDF with one form field and set text on it.
The text is clearly in the form (when viewed with PoDoFoBrowser 0.5
(win32)). Yet when I open the PDF in Adobe Reader (9.2.0, win32), the
field appears empty. When I click on the text field my value is
visible. When I click off of the field, my value disappears. (My
code is below)
I'm using the latest podofo from svn (rev 1199, checked out this
morning), and the PDF 1.3 spec from Adobe's web site [1]. I studied
the sample code in "podofo/test/FormTest" [2]. I skimmed most of the
PDF reference manual, and intently read (twice) section 7.6,
"Interactive Forms".
My ultimate goal is to write a routine that will read a third
party PDF (with a form on it), fill in the fields and save the form.
At a later time a user would then load the form into and further edit
it, email it and/or print it. When I failed to get this to work with
the desired forms (US / IRS tax form "941" [3]), I created a small app
to build a custom PDF with a simplified form. I get the same results
with both forms.
I've viewed both forms inside PoDoFoBrowser. Some annotation
elements have different attributes, but they are essentially the same.
I have three theories:
a) It is simply not possible to construct a PDF form with data
pre-populated using "PdfTextField.SetText()".
b) I'm doing something wrong.
c) I need to set some additional attributes or values in the
annotation element, or its parent object, or in the document object
itself.
At this time I can see only one possible hack: To read the form
field's "rects" and create a text overlay in the same position. This
is indeed a hack as this will prevent the user from properly editing
the form at a later time (prior to them printing or otherwise using
it).
Although I am using PoDoFoBrowser and Adobe Reader on win32, I am
doing my development on Gentoo Linux. This, hopefully, does not
matter.
I would very much appreciate any suggestions, assistance, etc...
If it would be helpful, I can post the "stuff" that PoDoFoBrowser
shows inside the forms. However, it is fairly easy to download the
"941" form and view it directly.
Thank you for your time.
[1] http://www.adobe.com/devnet/pdf/pdfs/PDFReference13.pdf
[2]
https://podofo.svn.sourceforge.net/svnroot/podofo/podofo/trunk/test/FormTest/FormTest.cpp
[3] http://www.irs.gov/pub/irs-pdf/f941.pdf
// "main()", "#include" and original error handling omitted for brevity.
// "HelloWorld" line shamelessly stolen from the PoDoFo online example.
void RunPdfTest (const char *filename)
{
PdfStreamedDocument doc (filename);
PdfPage *pPage = doc.CreatePage (PdfPage::CreateStandardPageSize
(ePdfPageSize_Letter));
PdfPainter painter;
painter.SetPage (pPage);
PdfFont *pFont = doc.CreateFont ("Arial");
pFont->SetFontSize (18.0);
painter.SetFont (pFont);
painter.DrawText (56.69, pPage->GetPageSize().GetHeight() - 56.69,
"Hello World!" );
PdfTextField text (pPage, PdfRect (100, 200, 300, 400), &doc);
text.SetFieldName ("text-field");
text.SetText ("test");
text.SetMultiLine (false);
painter.FinishPage ();
doc.Close();
}
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] Calling VC6, Borland, other Windows users (*IMPORTANT* FOR WINDOWS-BASED DEVELOPERS)
I meant to post this to the list, but accidentally sent it to Craig only. I can provide access to a Windows XP Pro instance (over RDP, running in VMWare) that has MSVC 6.0, SP6 and the Feb 2003 Platform SDK installed. Below is my original email/posting. MS VC 6.0 typically comes with a subscription to the MSDN kit. The kit includes lots of older utilities, operating systems, older copies of office, etc... Costs vary. A year or so ago Microsoft was running a promotion that the kit was $349/developer. But on their web sites prices start at $1000 and go up. Not very fun. I do have MSVC 6.0, which I use. I plan on using Podofo in a future (Linux based) project and joined the mailing list a few weeks ago to get a feel for the library and community. I can help you test things if you'd like. I can possibly provide you with remote desktop access to a Windows XP Pro virtual machine with the MSVC dev kit installed (but I need time to set it up. Do you have a static IP address (or at least a dynamic one in a small range)? If you want to discuss further, please contact me off-list (dennis dot jenkins dot 75 at gmail dot com). -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
