ANN: wxPdfDocument 0.9.0 released

Do you like to promote your wxWidgets based application or component!? Post it here and let's see what the critics have to say. Also, if you found that ONE wx component the world needs to know about, put it here for future reference.
Post Reply
utelle
Moderator
Moderator
Posts: 1125
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

ANN: wxPdfDocument 0.9.0 released

Post by utelle »

Version 0.9.0 of the wxCode component wxPdfDocument is available for download from http://sourceforge.net/projects/wxcode. The new version 0.9.0 is compatible with wxWidgets version 2.8.11 and version 2.9.1. Compatibility with older wxWidgets versions is not guaranteed. Sample PDF files created with wxPdfDocument can be found here.

This is the first release of wxPdfDocument containing a PDF drawing context (wxPdfDC) - although not all methods are implemented yet. There are implementations for wxWidgets 2.8.x and 2.9.x; the matching implementation is selected automatically at compile time. Please report your experiences with wxPdfDC to the author of wxPdfDocument, be it bug reports, contributions or feature requests.

Code for loading font data of a font identified by a wxFont object has been added for the wxMac platform, but due to lack of a Mac development environment it hasn't been tested thoroughly.

Edited (Jan 3, 2011): In the meantime it has been verified that the wxMac specific code works as expected - after several modifications :). Support for at least some Apple Unicode TrueType fonts has been added as well. The modified source files can be found in the wxCode SVN.

Changes in version 0.9.0

Added features:
- methods to draw Bezier splines through a list of points;
the drawing sample has been extended to show the new functionality
- PDF drawing context (wxPdfDC); not yet all methods are implemented
- support for fonts with VOLT (Visual Ordering and Layout Tables) data
(currently visual ordering only, preprocessing of the fonts required);
fonts for 9 Indic scripts are included to demonstrate this feature

General changes:
- increased output speed for method SaveAsFile (if large graphics files are involved)
- all currently supported CJK font families are now registered automatically at startup of the font manager
- MS CJK fonts aren't automatically registered as Type0 fonts,
since this conflicts with registering these fonts as TrueType Unicode fonts
- handling of image masks has been improved

Fixed bugs:
- opening font files could fail if the file path contained non-latin characters
Now wxFileSystem::FileNameToURL is used to create valid file names for use in method OpenFile of wxFileSystem
- invalid format codes in method wxPdfUtility::Double2String could cause problems in MinGW environment
- registering half-width CJK fonts didn't work
- bug in page size handling
- no file was written when Close was called before SaveAsFile
- bug in the handling of transparency for image masks
- uninitialized member variables in layer objects possibly causing invisibility of layers
- cleaned up output formatting codes for building on 64-bit systems
- compile time bugs for wxWidgets built with wxUSE_STL
- several minor bugs

Feedback and bug reports are welcome.

Regards,

Ulrich
Last edited by utelle on Mon Jan 03, 2011 6:37 pm, edited 1 time in total.
Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria »

Hi,

on OSX you need to add this to pdffontmacosx.h :

Code: Select all

#include <CoreFoundation/CoreFoundation.h>
#include <ApplicationServices/ApplicationServices.h>
but after fixing this I get :

Code: Select all

./src/pdffontdataopentype.cpp: In member function ‘virtual size_t wxPdfFontDataOpenTypeUnicode::WriteFontData(wxOutputStream*, wxPdfSortedArrayInt*, wxPdfChar2GlyphMap*)’:
./src/pdffontdataopentype.cpp:509: error: ‘m_fontRef’ was not declared in this scope
seems like there it some confusion between wxPdfFontDataOpenTypeUnicode and wxPdfFontParserTrueType in your code; wxPdfFontParserTrueType is the one that has m_fontRef, so obviously it's wrong to refer to m_fontRef from wxPdfFontDataOpenTypeUnicode
"Keyboard not detected. Press F1 to continue"
-- Windows
utelle
Moderator
Moderator
Posts: 1125
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Post by utelle »

Thanks for checking the wxMac build!
Auria wrote:on OSX you need to add this to pdffontmacosx.h :

Code: Select all

#include <CoreFoundation/CoreFoundation.h>
#include <ApplicationServices/ApplicationServices.h>
I added these includes for the case when core text fonts are used (wxPDFMACOSX_HAS_CORE_TEXT=1). Other includes might be required in case of when the older ATSU fonts are used (wxPDFMACOSX_HAS_ATSU_TEXT=1).
Auria wrote:but after fixing this I get :

Code: Select all

./src/pdffontdataopentype.cpp: In member function ‘virtual size_t wxPdfFontDataOpenTypeUnicode::WriteFontData(wxOutputStream*, wxPdfSortedArrayInt*, wxPdfChar2GlyphMap*)’:
./src/pdffontdataopentype.cpp:509: error: ‘m_fontRef’ was not declared in this scope
seems like there it some confusion between wxPdfFontDataOpenTypeUnicode and wxPdfFontParserTrueType in your code; wxPdfFontParserTrueType is the one that has m_fontRef, so obviously it's wrong to refer to m_fontRef from wxPdfFontDataOpenTypeUnicode
Since for OpenType fonts (PostScript flavor) I only need to access a single font table, namely the CFF table, the font parser is not used in that case. Instead the table is accessed directly. The reference to m_fontRef is simply a typo: it should read "fontRef" without the "m_" prefix.

Both issues are corrected in the wxCode SVN.

Regards,

Ulrich
Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria »

Thanks.

Now I have a few more for you ;)

Code: Select all

./src/pdffontparsertruetype.cpp: In member function ‘wxPdfFontData* wxPdfFontParserTrueType::IdentifyFont(const wxFont&)’:
./src/pdffontparsertruetype.cpp:705: error: ‘class wxPdfFontData’ has no member named ‘SetFont’
./src/pdffontparsertruetype.cpp: In member function ‘bool wxPdfFontParserTrueType::LoadFontData(wxPdfFontData*)’:
./src/pdffontparsertruetype.cpp:787: error: ‘class wxPdfFontData’ has no member named ‘GetFont’
./src/pdffontparsertruetype.cpp: In member function ‘bool wxPdfFontParserTrueType::ReadTableDirectory()’:
./src/pdffontparsertruetype.cpp:984: error: invalid conversion from ‘char* (*)(const char*, int)’ to ‘CFIndex’
./src/pdffontparsertruetype.cpp:984: error:   initializing argument 2 of ‘const void* CFArrayGetValueAtIndex(const __CFArray*, CFIndex)’
./src/pdffontparsertruetype.cpp:988: error: invalid conversion from ‘const char*’ to ‘char*’
./src/pdffontparsertruetype.cpp:988: error:   initializing argument 1 of ‘int wxPdfFontParserTrueType::CalculateChecksum(char*, size_t)’
./src/pdffontparsertruetype.cpp:989: error: expected ‘,’ or ‘;’ before ‘CFRelease’
./src/pdffontparsertruetype.cpp:1001: error: conversion from ‘CTFontTableTag’ to ‘const wxString’ is ambiguous
Of course,

Code: Select all

int checksum = CalculateChecksum((const char*) tableData, (size_t) tableLen)
needs to be

Code: Select all

int checksum = CalculateChecksum((const char*) tableData, (size_t) tableLen); // <-- semicolon
Then, CalculateChecksum needs to take a "const char*" as argument and not a char*

Then, in

Code: Select all

CTFontTableTag tag = (CTFontTableTag)(uintptr_t) CFArrayGetValueAtIndex(tables, index);
"index" does not appear to be declared

Regarding the other errors, I don't know your code enough to know what you're trying to do :)
"Keyboard not detected. Press F1 to continue"
-- Windows
utelle
Moderator
Moderator
Posts: 1125
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Post by utelle »

Auria wrote:Now I have a few more for you ;)
Most probably not the last ones. :(
Auria wrote:

Code: Select all

./src/pdffontparsertruetype.cpp: In member function ‘wxPdfFontData* wxPdfFontParserTrueType::IdentifyFont(const wxFont&)’:
./src/pdffontparsertruetype.cpp:705: error: ‘class wxPdfFontData’ has no member named ‘SetFont’
./src/pdffontparsertruetype.cpp: In member function ‘bool wxPdfFontParserTrueType::LoadFontData(wxPdfFontData*)’:
./src/pdffontparsertruetype.cpp:787: error: ‘class wxPdfFontData’ has no member named ‘GetFont’
./src/pdffontparsertruetype.cpp: In member function ‘bool wxPdfFontParserTrueType::ReadTableDirectory()’:
./src/pdffontparsertruetype.cpp:984: error: invalid conversion from ‘char* (*)(const char*, int)’ to ‘CFIndex’
./src/pdffontparsertruetype.cpp:984: error:   initializing argument 2 of ‘const void* CFArrayGetValueAtIndex(const __CFArray*, CFIndex)’
./src/pdffontparsertruetype.cpp:988: error: invalid conversion from ‘const char*’ to ‘char*’
./src/pdffontparsertruetype.cpp:988: error:   initializing argument 1 of ‘int wxPdfFontParserTrueType::CalculateChecksum(char*, size_t)’
./src/pdffontparsertruetype.cpp:989: error: expected ‘,’ or ‘;’ before ‘CFRelease’
./src/pdffontparsertruetype.cpp:1001: error: conversion from ‘CTFontTableTag’ to ‘const wxString’ is ambiguous
Of course,

Code: Select all

int checksum = CalculateChecksum((const char*) tableData, (size_t) tableLen)
needs to be

Code: Select all

int checksum = CalculateChecksum((const char*) tableData, (size_t) tableLen); // <-- semicolon
Then, CalculateChecksum needs to take a "const char*" as argument and not a char*

Then, in

Code: Select all

CTFontTableTag tag = (CTFontTableTag)(uintptr_t) CFArrayGetValueAtIndex(tables, index);
"index" does not appear to be declared

Regarding the other errors, I don't know your code enough to know what you're trying to do :)
I hopefully fixed all errors you pointed out.

SetFont/GetFont are methods of wxPdfFontData which were only available in wxMSW build. I activated them for wxMac, too.

I changed the type of the first parameter of method CalculateChecksum to const char* and added the missing semicolon.

I committed the changed source files

pdffontdata.h
pdffontparsertruetype.h
pdffontparsertruetype.cpp

to wxCode SVN.

Regards,

Ulrich
Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria »

Hi,

victory :) Just remove those "SetFile" lines from the makefiles, those come from Mac OS 9 (over a decade ago) and are not to be used on OSX

Also, re the printing sample, the proper include for the generic margins dialogs is :

Code: Select all

#ifdef __WXMAC__
    #if wxMAJOR_VERSION > 2 || (wxMAJOR_VERSION == 2 && wxMINOR_VERSION == 9)
    #include <wx/osx/printdlg.h>
    #else
    #include <wx/mac/carbon/printdlg.h>
    #endif
#endif
See attached the output of the minimal sample :)
Attachments
wxPDF.zip
(481.47 KiB) Downloaded 156 times
"Keyboard not detected. Press F1 to continue"
-- Windows
utelle
Moderator
Moderator
Posts: 1125
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Post by utelle »

Auria wrote:victory :)
... although not yet complete ... the samples not using core fonts don't produce correct PDF files. Obviously the font files were not found. Could you please define the environment variable WXPDF_FONTPATH and let it point to the lib/fonts folder of the wxPdfDocument distribution and then run 'tutorial7' and 'indicfonts' again?
Auria wrote:Just remove those "SetFile" lines from the makefiles, those come from Mac OS 9 (over a decade ago) and are not to be used on OSX
I use bakefile to create all build files. I'll have to check what I have to change to suppress the generation of those "SetFile" lines.
Auria wrote:Also, re the printing sample, the proper include for the generic margins dialogs is :

Code: Select all

#ifdef __WXMAC__
    #if wxMAJOR_VERSION > 2 || (wxMAJOR_VERSION == 2 && wxMINOR_VERSION == 9)
    #include <wx/osx/printdlg.h>
    #else
    #include <wx/mac/carbon/printdlg.h>
    #endif
#endif
Thanks. I changed printing.cpp in wxCode SVN.
Auria wrote:See attached the output of the minimal sample :)
It's good to see that most samples produce the expected results, except the two mentioned above.

To check whether the new wxMac font loading code works as intended could you please try to run the printing sample (samples/pdfdc) and inspect the resulting PDF file default.pdf?

Thank you very much for your assistance.

Regards,

Ulrich
Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria »

Regarding the sample, ideally one of the 2 solutions described at http://wiki.wxwidgets.org/WxMac_Issues# ... e_front.21 should be implemented, otherwise the sample cannot be used without manually packaging it inside an app bundle

Also I had some issues with :

Code: Select all

    wxImage image( wxT("../samples/pdfdc/smile.jpg") );
First of all, you rely on CWD instead of using wxStandardPaths, tsk tsk ;) then it would be nice to have something like :

Code: Select all

    if (!image.IsOk())
    {
        wxMessageBox("Cannot open image ../samples/pdfdc/smile.jpg");
        exit(1);
    }
so that failure to find the image doesn't result in an obscure crash.

"default.pdf" is attached (I'm not sure what I need to check for)

On a related note, the makefile contains 2 strings :

Code: Select all

__minimal___mac_setfilecmd = (path to minimal sample here)
...
__dcsample___mac_setfilecmd = (path to dc sample here)
By default, these strings seem used to run each sample as soon as it's built. Is that intended? It's quite annoying :D
Attachments
default.pdf.zip
(8.16 KiB) Downloaded 159 times
"Keyboard not detected. Press F1 to continue"
-- Windows
utelle
Moderator
Moderator
Posts: 1125
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Post by utelle »

Auria wrote:Regarding the sample, ideally one of the 2 solutions described at http://wiki.wxwidgets.org/WxMac_Issues# ... e_front.21 should be implemented, otherwise the sample cannot be used without manually packaging it inside an app bundle
Since I don't have a wxMac environment where I could test I rely on bakefile to create usable build files. I'd like to know whether the official wxWidgets samples work out of the box. If yes, I could try to figure out, what is done different as in my bakefile script.
Auria wrote:Also I had some issues with:

Code: Select all

    wxImage image( wxT("../samples/pdfdc/smile.jpg") );
First of all, you rely on CWD instead of using wxStandardPaths, tsk tsk ;)
I changed the samples to set the executable path as the current working directory. This should avoid the problems.
Auria wrote:"default.pdf" is attached (I'm not sure what I need to check for)
Well, I think I have to design a special wxMac test case. It seems that the default font on Mac is Helvetica or Arial (at least on your machine) and therefore wxPdfDC uses the PDF core font Helvetica - and doesn't load any font. So the new code isn't executed at all.
Auria wrote:On a related note, the makefile contains 2 strings:

Code: Select all

__minimal___mac_setfilecmd = (path to minimal sample here)
...
__dcsample___mac_setfilecmd = (path to dc sample here)
By default, these strings seem used to run each sample as soon as it's built. Is that intended? It's quite annoying :D
It's certainly not intended, but I feel it's a bakefile issue since the file Makefile.in is generated by bakefile. As far as I can see the Makefile.in files of all wxWidgets samples contain those lines, too. Do the wxWidgets samples show the same behaviour on a Mac?

Unfortunately I don't see a quick solution. It's too bad that bakefile fails to generate xCode build files - although I don't know whether this is due to missing parts in the wxCode bakefile presets or due to problems with bakefile itself.

Regards,

Ulrich
Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria »

The bakefile system used by the wxWidgets core package does work correctly on OSX for all mentionned uses (not that the current wxWidgets core still has bakefiles generated the old unusable classic application, but an appropriate app bundle for OSX is also generated)
"Keyboard not detected. Press F1 to continue"
-- Windows
utelle
Moderator
Moderator
Posts: 1125
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Post by utelle »

Auria wrote:The bakefile system used by the wxWidgets core package does work correctly on OSX for all mentionned uses (not that the current wxWidgets core still has bakefiles generated the old unusable classic application, but an appropriate app bundle for OSX is also generated)
In the meantime I had contact to one of the wxWidgets core developers. It seems that in the wxCode bakefile presets the special handling for the Mac platform is missing. I'll try to find a solution.

Regards,

Ulrich
utelle
Moderator
Moderator
Posts: 1125
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Post by utelle »

Update: After several modifications the wxMac specific code works as expected at last. On request support for at least some Apple Unicode TrueType fonts has been added as well. The modified source files can be found in the wxCode SVN. An updated file release will be made in the near future.

The issue with the wxCode bakefile presets regarding the special handling for the Mac platform is still open.

Regards,

Ulrich
Post Reply