utelle / wxpdfdoc

wxPdfDocument - Generation of PDF documents from wxWidgets applications
http://utelle.github.io/wxpdfdoc/
Other
70 stars 27 forks source link

Compile Error in Unicode Mode with UTF8 #66

Closed DarthAlSith closed 4 years ago

DarthAlSith commented 4 years ago

Hi. I compiled wxWidgets-3.0.4 with UTF8 encoding. When I try to compile wxPdfdoc-0.9.7 with the wx-config file of the version compiled before it gives me the error:

"pdfcffdecoder.cpp:XXX:Y: error: cannot convert 'const char' to 'const wxChar {aka const wchar_t*}' in initialization"

how can I solve it? Can you help me?

utelle commented 4 years ago

Please provide more detailed information:

Additionally, I would recommend to use the latest release 0.9.8 of wxPdfDocument.

DarthAlSith commented 4 years ago

Sorry.. that careless..

Which platform do you use?

I need to compile it on both Linux and Windows, and now I'm starting on Linux

Which compiler?

g++

Which build system? (configure, VC++ solution, makefile)

I configure wxWidgets-3.0.4 as: CPPFLAGS="-std=c++98" ./configure --enable-monolithic --enable-debug --enable-utf8 --disable-std_string --without-gtkprint --disable-compat28 --without-subdirs and then configure wxPdfDoc-0.9.7 as: CPPFLAGS="-std=c++98" ./configure --with-wx-config=../wxWidgets-3.0.4-debug/wx-config To compile I launch make command

At which line number in pdfcffdecoder.cpp do you get this compile error? XXX:Y does not allow to identify the cause.

I get the error at the lines 157 and 172.

PS: I decided to use 0.9.7 version, after I read that it's latest stable

DarthAlSith commented 4 years ago

It seems to be solved. I compiled without errors changing the use of MACRO wxS() with wxT() in the following files:

minimal/labels.cpp src/pdfcffdecoder.cpp src/pdffontmanager.cpp src/pdffontparsertruetype.cpp src/pdffontsubsettruetype.cpp src/pdfkernel.cpp src/pdfparser.cpp src/pdfcjkfontdata.inc src/pdfcmapdata.inc src/pdfcodepagedata.inc src/pdfcolourdata.inc src/pdfcorefontdata.inc src/pdfglyphnames.inc

What do you think about? Compile goes ok; now I try to insert these libraries in my program and test its usage.

utelle commented 4 years ago

PS: I decided to use 0.9.7 version, after I read that it's latest stable

Where did you read that??? This is simply not true.

I strongly recommend to use version 0.9.8 as it adds alpha transparency support for wxPdfDC and a few other useful things.

I configure wxWidgets-3.0.4 as: CPPFLAGS="-std=c++98" ./configure --enable-monolithic --enable-debug --enable-utf8 --disable-std_string --without-gtkprint --disable-compat28 --without-subdirs

I fear that the compile error you get might be a side effect of the option --enable-utf8 as it modifies the definition of the string macro wxS. I know that wxPdfDocument compiles flawlessly with the wxWidgets default build configuration (which uses UTF8 for internal string representation anyway as far as I know).

You could try to modify line 147 (resp line 163) by replacing wxChar* by wxString:

static const wxString gs_subrsFunctions[] = {

I have not tested this myself, but it might solve the issue. However, this type of initialization is used in various other source files of wxPdfdoucument as well. Therefore you should maybe reconsider whether you really need compile option --enable-utf8.

utelle commented 4 years ago

It seems to be solved.

Good news.

I compiled without errors changing the use of MACRO wxS() with wxT() in the following files: [...]

As mentioned in my previous post this type of initialization with macro wxS is used in several source files of wxPdfDocument.

What do you think about?

Well, in earlier versions of wxPdfDocument I used the macro wxT throughout the whole source code. However, it was recommended to use wxS for better compatibility with wxWidgets 3.x. So I changed from wxT to wxS.

While wxT always creates wide strings independent of the UTF8 setting, wxS does not if UTF8 is enabled.

Compile goes ok; now I try to insert these libraries in my program and test its usage.

In principle the program should work if it compiles without errors. But since I never used option --enable-utf8 myself I have no idea whether it might still cause problems at runtime.

Since I intend to drop compatibility with wxWidgets 2.8.x anyway, I will consider to rewrite the code to avoid such problems for future versions of wxPdfDocument.

vadz commented 4 years ago

Just for the record, wx doesn't use UTF-8 by default. And wxS() is not equivalent to wxT(), it's intentionally different from it in UTF-8 build so that you can use have a literal of the same type that is used by wxString by default -- which is not the case with wxT() in UTF-8 build. However wxChar is still wchar_t even in UTF-8 build, which probably explains the errors.

I.e. in UTF-8 build the type used by wxString internally is not the same wxChar.

utelle commented 4 years ago

Thanks for the clarification, Vadim.

The reasoning behind using wxChar* for static string constants in wxPdfDocument was to avoid the creation of tons of wxString objects. This worked without issues for wxWidgets 2.8.x and at least for default builds for wxWidgets 3.x.

I have to admit that I wasn't aware of the differences between wxS and wxT in UTF-8 builds. The question is what would be the most appropriate approach to fix the issue for UTF-8 builds without breaking anything else.

vadz commented 4 years ago

One possibility is to use wxStringCharType instead of wxChar: this would allow the code using wxS() compile in all build variants, I think. However wxStringCharType doesn't exist in 2.8, so you'd have to use some wxPdfDocCharType and define it as wxChar with 2.8.

utelle commented 4 years ago

I will consider to introduce such an approach. However on the other hand, I think the time has come to drop 2.8 compatibility.

DarthAlSith commented 4 years ago

Thank you guys.

One possibility is to use wxStringCharType instead of wxChar: this would allow the code using wxS() compile in all build variants, I think. However wxStringCharType doesn't exist in 2.8, so you'd have to use some wxPdfDocCharType and define it as wxChar with 2.8.

I'll try to use the solution suggested by vadz.. I update you

DarthAlSith commented 4 years ago

UPDATE: the files to modify are the same that in the previous case:

minimal/labels.cpp src/pdfcffdecoder.cpp src/pdffontmanager.cpp src/pdffontparsertruetype.cpp src/pdffontsubsettruetype.cpp src/pdfkernel.cpp src/pdfparser.cpp src/pdfcjkfontdata.inc src/pdfcmapdata.inc src/pdfcodepagedata.inc src/pdfcolourdata.inc src/pdfcorefontdata.inc src/pdfglyphnames.inc

I was able to apply vadz's solution in the most chance, except 2 files:

src/pdfcjkfontdata.inc src/pdfcorefontdata.inc

For these, it seemed, at first look, more articulated proceed as others and so I defined static arrays' texts with macro wxT() Now, I'm going to test it.

utelle commented 4 years ago

Since wxWidgets recommends to avoid the use of macro wxT for version 2.9 and above, I'd like to avoid to reintroduce it in wxPdfDocument, although this approach may be the quickest solution for your use case.

Instead I now plan to drop support for wxWidgets 2.8.x (last release was in 2011 - almost 9 years ago). In this course I will remove all those static wxChar constants. However, this process will take some time.

DarthAlSith commented 4 years ago

Ok utelle. now, sorry for the shameful question .. how come a dynamic library is not created ..?? .. it didn't seem like there was a parameter to be forced.

utelle commented 4 years ago

AFAIK creating shared libraries should be the default under Linux. If that doesn't work for you, I'm at a loss unfortunately, because I do most of my development under Windows. Maybe @vadz has an idea what could have been gone wrong.

utelle commented 4 years ago

I made a quick check under Linux using the default build configuration. The shared libraries are created as expected.

DarthAlSith commented 4 years ago

Hi utelle. Could you show me the compilation command that you used?

utelle commented 4 years ago

Well, as said I used default configurations. I compiled wxWidgets 3.1.3 as descibed in its documentation using

mkdir build-gtk
cd build-gtk
../configure --with-gtk
make

and - with a fresh copy of wxPdfDocument 0.9.8 -

autoreconf
mkdir build-gtk
cd build-gtk
../configure
make

Maybe one thing to mention is that libtool is used for wxPdfDocument, that is, the shared libraries are created in subdirectory .libs of the build directory.

DarthAlSith commented 4 years ago

I used: -for wxWidgets-3.0.4: CPPFLAGS="-std=c++98" ./configure --enable-monolithic --enable-debug --disable-std_string --without-gtkprint --disable-compat28 --without-subdir

-for wxPdfDoc-0.9.8: CPPFLAGS="-std=c++98" ./configure --with-wxdir="../wxWidgets-3.0.4-debug"

In addition, in the last rows of configure's output I read: .... checking for wxWidgets static library... Warning: No config found to match ... checking if wxWidgets was built with UNICODE enabled... yes checking if wxWidgets was built in DEBUG mode... no checking if wxWidgets was built in STATIC mode... no ..but I compiled wxWidgets in Debug Mode

utelle commented 4 years ago

IMHO you need to specify the debug option explicitly. Simply referencing the wx directory is not enough, because you could have several different builds in that directory. So, maybe try to add option --enable-wxdebug (and possibly --enable-debug).

DarthAlSith commented 4 years ago

Ok. I try this configuration:

utelle commented 4 years ago

I can't explain the error message you get from libtool. However, I can confirm that the options --enable-debug and --enable-wxdebug are not recognized. Again, I don't know why that is so.

The configure support for wxPdfDocument was initially provided by @vadz. So I hope he can shed some light on those issues.

vadz commented 4 years ago

I try this configuration:

* configure and compile wxWidgets-3.1.3 in debug mode, in a specific 'build-x' dir: OK.

* configure wxpdfdoc-0.9.8, from relative 'build-x' dir, with command: `CPPFLAGS="-std=c++98" ../configure WX_CONFIG="../../wxWidgets-3.1.3-debug/build-x/" --enable-wxdebug --enable-debug`  ...and configuration seems go ok, but gives me warning `unrecognized options: --enable-wxdebug, --enable-debug`

This is wrong, WX_CONFIG needs to be set to the location of wx-config, which is missing at the end of your path. If you want to use a directory, you can use --with-wxdir=PATH option instead.

Also, --enable-wxdebug is not really useful, I'm not sure why do you use it.

utelle commented 4 years ago

Well, I'm to blame for that @DarthAlSith tried out option --enable-wxdebug. I asked him to try it in a previous post. In fact, neither --enable-debug nor --enable-wxdebug are recognized by wxPdfDocument's configure script. How can debug mode be enabled for wxPdfDocument then?

vadz commented 4 years ago

How can debug mode be enabled for wxPdfDocument then?

There is no debug mode in the current configure. It's not really clear to me what would it do -- -g is used by default anyhow. In fact, the main use of it I can see is to make --disable-debug disable the use of -g and define NDEBUG.

utelle commented 4 years ago

The OP asked for debug mode.

I had the impression that with wxWidgets 3.x there is no separate debug build anymore at least under Linux. However, the build instructions for wxWidgets itself clearly make a distinction between release and debug build.

Personally, I develop and test mostly under Windows. I usually verify that all functions properly under Linux, but I seldom need to debug under Linux.

vadz commented 4 years ago

Yes, in 3.x there is one default build, which includes debug helpers which can be activated or not by the application. So for an application, it might make sense to use some configure option to disable asserts. But I don't really think --enable-debug makes much sense for a library such as wxPdfDoc.

utelle commented 4 years ago

You are right. In fact, wxPdfDocument does not have any debug specific code except for several calls to wxLogDebug.

DarthAlSith commented 4 years ago

Hi guys. Ok about debug option for wxPdfDoc.. I understand. My problem is still that I'm not able to obtain shared library for wxpdfdoc.

The last working configuration is:

how can we solve?

utelle commented 4 years ago

File libwxcode_gtk2u_pdfdoc-3.0.la should be a rather small libtool text file containing references to the shared library files located in subdirectory .libs of the build directory. For linking you then use libtool (see Linking executables using libtool).

DarthAlSith commented 4 years ago

Ok, I'll look at it. Thanks.

utelle commented 4 years ago

Now closing, since the issue is related to build tools and not wxPdfDocument itself.

Feel free to reopen if necessary.