Hi Wim,

Craig is the CMake specialist in our team, so it is always better to send this 
stuff to the mailinglist as more people can take a look onto this.

Strangely I never had problems when building PoDoFo with libJpeg on Windows 
with Visual Studio. Did you add something like "-DCMAKE_INCLUDE_PATH=c:
\progra~1\gnuwin32\include" to the commandline when invoking cmake so that 
the include path is added? According to the readme and my experiences this is 
neeeded.

regards
        Dom

Am Samstag, 27. Dezember 2008 schrieb Wim Vandenhende:
> Hi Dominik,
>
> I promised to send you my code but I'm not done yet, and still need to
> clean it up first too. (I'll check on PoDoFo's coding standards)
> On the side I'm making a virtual machine with Windows XP and am
> installing everything to program in it. (should've done that alot earlier)
>
> I'm again trying to build PoDoFo using CMake (got it from the svn this
> time), and I got the same problem with it as I had before.
> The LIBJPEG_INCLUDE_DIR var is not added to the entry list in CMake,
> while the two library vars are.
>
> After checking the CMake docs, MARK_AS_ADVANCED(LIBJPEG_LIBRARY
> LIBJPEG_INCLUDE_DIR ) causes this.
> This has maybe something to do with that it is not needed to build
> PoDoFo? But this is not done for TIFF and some other libs.
> Strange thing is also that only the include dir var isn't added, the
> other two lib vars are.
> So is this working as intended? I find it pretty annoying.
>
> You'll get the source code as soon as I'm done. (and my client is happy
> :-))
>
> Greetings,
> Wim Vandenhende
>
> Dominik Seichter wrote:
> > Hi Wim,
> >
> > Am Sonntag, 14. Dezember 2008 schrieben Sie:
> >> Hi Dominik,
> >>
> >> Thanks for the answers.
> >> I'm not a big fan of the Microsoft way either, but we have to deal with
> >> it.
> >>
> >> I'm currently finishing my program, it should be done next week.
> >> I'll extract the PDF part and will send you the sources by the end of
> >> next week.
> >
> > Thanks!
> >
> >> Btw, two quick questions:
> >> - how do I put compression on a document?
> >> I've seen the filters but can't find out how to use them with
> >> PdfStreamedDocument/PdfPainter ?
> >
> > PdfPainter uses the FlateDecode filter automatically. This should be the
> > best choice for streams anyway. If you have different needs,
> > PdfPainter::SetPage contains the call to PdfStream::BeginAppend( ). You
> > could adapt it to use a differenct overload which you could use to
> > specify filters.
> >
> >> - Am I not allowed to get a page with PdfStreamedDocument::GetPage(x)
> >> and set it with PdfPainter::SetPage() ?
> >> (gives an error (Run-Time Check Failure #0) in PdfVariant::DelayedLoad)
> >
> > PdfStreamedDocument is for writing only. Once a page is Finished it is
> > written immediately to disk and you are not allowed to retrieve later
> > again. If you application needs this, you might want to use
> > PdfMemDocument instead.
> >
> > best regards,
> >     Dom
> >
> >> Greets,
> >> Wim
> >>
> >> Dominik Seichter wrote:
> >>> Hello Wim,
> >>>
> >>> I am glad you like PoDoFo and I am very interested in your changes.
> >>>
> >>> The table model stuff was a very quick hack, which I needed for some
> >>> project, so I only had time to start with the interfaces and implement
> >>> the most basic stuff. Therefore I really appreciate any improvements.
> >>>
> >>> AFAIK the include directory problem with VC2005 has already been fixed,
> >>> but I will check against your sources.
> >>>
> >>> Undefining DrawText is necessary before including podofo.h. I really
> >>> hate this, but I do not know of any better way. I don't really like the
> >>> Microsoft approach here very much. Defining common method names like
> >>> DrawText or DrawObject is really a problem for anyone writing libraries
> >>> which do some form of drawing similar to GDI.
> >>>
> >>> Regarding the font bug in column headers, I can't really see what could
> >>> be the problem. Do you have some sample code?
> >>>
> >>> I just tested CreationTest for memory leaks using valgrind and there
> >>> are indeed some memory leaks in the code. I'll take a look on fixing
> >>> them.
> >>>
> >>> best regards,
> >>>   Dom
> >>>
> >>> Am Sonntag, 14. Dezember 2008 schrieben Sie:
> >>>> Hello Dominik,
> >>>>
> >>>> First of all, nice work on a very nice C++ PDF library, I love it.
> >>>> (used LibHaru before)
> >>>>
> >>>> I have been working with it for some weeks now, and have changed a
> >>>> bit. Especially the table classes to have a more dynamic interface.
> >>>>
> >>>> I've had a few problems in compiling and using the library, but found
> >>>> work arounds.
> >>>> I send you this personal email because I don't know if I can post this
> >>>> on the mail list because it involves all sorts of things. I hope it's
> >>>> ok.
> >>>>
> >>>>
> >>>> - I had some compiling problems on Windows, but fixed most of it.
> >>>> CMake is working pretty well but the VC2005 projects missed the
> >>>> library and their include directories and references. I think I saw a
> >>>> patch for this already?
> >>>>
> >>>> - When using the DrawText and CreateFont functions the compiler used
> >>>> the win32 macros and tried to link to DrawTextA and CreateFontA. I
> >>>> undeffed them before including podofo.h. Don't know if it is the way
> >>>> it should be done.
> >>>>
> >>>> - I don't know what caused it, but it might be using fonts in a table
> >>>> (I specify a font pointer for each cell, created in my main class). A
> >>>> pure virtual function was called in the PdfFont destructor
> >>>> (m_pEncoding->IsAutoDelete()). To fix this I just returned false in
> >>>> the interface, so it isn't pure virtual anymore.
> >>>> Afterwards I also had problems when running the PDF generation a
> >>>> second time. I think the PdfFont pointer I specified for the column
> >>>> headers of the table became invalid, because it crashed on
> >>>> PdfFont::GetFontMetrics() (access violation on the return). I tried
> >>>> deleting the font after the Draw function but seems the whole PdfFont
> >>>> pointer is invalid.
> >>>> Is this a bug?
> >>>>
> >>>> - When running a PDF generation multiple times, I see the memory usage
> >>>> going up every time. (about 1 MB). I tried to do the same in the
> >>>> CreationTest and helloworld examples (while loop in the main), and the
> >>>> same happens. So this looks like a memory leak in PoDoFo to me.
> >>>>
> >>>>
> >>>> So I extended the PdfTable and PdfTableModel classes a bit to have
> >>>> more options in creating dynamic tables.
> >>>> I have fixed the wordwrap (wasn't working very well here) and made a
> >>>> simple algorithm to distribute column widths over the maximum table
> >>>> width. (each cell gets a percentage of the tables width according to
> >>>> the text it contains)
> >>>> If you want I can send you the code to fit it into the existing
> >>>> classes. I actually don't have time to do this myself. (and should
> >>>> learn some SVN too I guess, I'm used to MKS)
> >>>>
> >>>>
> >>>> Greetings,
> >>>> Wim Vandenhende



-- 
**********************************************************************
Dominik Seichter - [email protected]
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
SchafKopf - http://schafkopf.berlios.de - Schafkopf, a card game,  for KDE
Alan - http://alan.sf.net - A Turing Machine in Java
**********************************************************************

Attachment: signature.asc
Description: This is a digitally signed message part.

------------------------------------------------------------------------------
_______________________________________________
Podofo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users

Reply via email to