Code::Blocks Forums
User forums => Help => Topic started by: agajania on March 09, 2011, 11:17:27 pm
-
When using Code::Blocks in Linux, the Print.. option produces a poor printout of the source code in the editor.
A bug report for this problem has been filed. It can be found at http://developer.berlios.de/bugs/?func=detailbug&bug_id=17990&group_id=5358 (http://developer.berlios.de/bugs/?func=detailbug&bug_id=17990&group_id=5358).
-
http://developer.berlios.de/bugs/?func=detailbug&bug_id=17990&group_id=5358 (http://developer.berlios.de/bugs/?func=detailbug&bug_id=17990&group_id=5358).
To my knowledge scintilla has no print API. We use wxWidgets for printing. Hence I believe you didn't use the "source exporter" plugin. It is there to create pretty print documents out of source code which should solve your issue.
-
To my knowledge scintilla has no print API. We use wxWidgets for printing. Hence I believe you didn't use the "source exporter" plugin. It is there to create pretty print documents out of source code which should solve your issue.
Thank you for your reply.
Scintilla's print API is documented at http://www.scintilla.org/ScintillaDoc.html#Printing (http://www.scintilla.org/ScintillaDoc.html#Printing).
I haven't gone through Code::Blocks source code to determine the code paths for printing. However, when I select the Print... option in the File Menu, a Print... dialog comes up with options that are similar to the options in the Scintilla printing function SCI_SETPRINTCOLOURMODE(int mode).
I have two issues with the source exporter plugin. First, it doesn't format well code that has been indented with tab characters. Second, after you export source code to a file, you have to find another way to print that file. This extra step is OK for me, but it is best to keep things simple for students who are learning programming.
-
I have two issues with the source exporter plugin. First, it doesn't format well code that has been indented with tab characters. ...
I just did a quick check, and you are right. Replacing tab with the remaining number of spaces needed to match the settings should do the trick. I was completely unaware of that issue (I do not use tabs to start with, so that little detail went unnoticed).
[edit]
Fixed :D
It should be available in the next nightly.
[/edit]
-
I just did a quick check, and you are right.
Oh - I understood this completely different. Good to know you took care.
While we are at it: I've a patch pending that completely updates the source exporter plugin to a recent wxPDFDoc. I didn't commit so far because of missing linux build support. Shall we do this together in a branch (e.g. wxSmith)?
-
While we are at it: I've a patch pending that completely updates the source exporter plugin to a recent wxPDFDoc. I didn't commit so far because of missing linux build support. Shall we do this together in a branch (e.g. wxSmith)?
A branch? Why? The trunk is sexier :D
If the whole idea is just to replace the pdf library with the most recent version, I could give it a try both in Winblows and Linux. Is there anything else in the patch other than just updating those files?
I think we should continue this discussion via PM, chat, e-mail or something alike. In case we continue hijacking this post, I will need to get a thief mask or something else that combines.
-
A branch? Why? The trunk is sexier :D
Because a commit would ultimately break compilation of trunk under Linux. I don't want tat.
And yes: It's basically a major update of wxPDF.
-
Because a commit would ultimately break compilation of trunk under Linux. I don't want tat.
My idea was to ensure that it compiles and works both in Winblows and Linux, so committing to trunk would not be a problem as long as I achieve that, right?
-
so committing to trunk would not be a problem as long as I achieve that, right?
OK - go ahead! Automake and unix project files need an update now. BTW: I had to patch wxPDFDoc to work properly as DLL. I'll comment/document that later.
Check the C::B project files for needed compiler flags (#define's).
-
I see that you have committed to trunk already, so I will check in Linux soon.
[edit]
I have been checking on Windows so far, and the project is building extra programs that we do not need. I also see that wxPDFDocument is now built as a DLL instead of being statically linked. Do we really want that?
[/edit]
-
[edit]
Do we really want that?
[/edit]
I wanted that, yes - because other 3rd party libs (wxprogrid, wxflatnb, wxchartctrl...) we provide as dynamic libs as well. So my intention was to be consistent. If it's a 3rd party lib - make it dynamically linked. However, you've probably noticed the issues with wxscintilla, so there might also be drawbacks. As you've disabled it it's gone now. But I can live with that. Just make sure it's the same style on all platforms.
-
I got it to compile in Linux both as a project file and with autotools, but there is a freaking sigsev when creating the PDF for which I have not been able to do any debugging. There seems to be something terribly wrong as well with Code::Blocks as it is all messed up if I try to debug it through Code::Blocks itself, or even run it from the output directory. All GDB gives me is a backtrace with the methods being called, but no source file/line information. All I know is that something goes wrong when calling wxPdfFontManager::GetFont(wxString const&, int) const (). I am using the non-stripped, -g enabled, .so, so why is it failing? :x
[edit]
I finally got GDB to find the sources, I am looking into the problem now...
[/edit]
-
[edit]
I finally got GDB to find the sources, I am looking into the problem now...
[/edit]
You shall not use -DwxPG_USE_WXMODULE=1 when using wxPDFDoc as static lib. I forgot to tell that.
-
[edit]
I finally got GDB to find the sources, I am looking into the problem now...
[/edit]
You shall not use -DwxPG_USE_WXMODULE=1 when using wxPDFDoc as static lib. I forgot to tell that.
Right, that was the problem. I have got it working with autotools and also with the project file. Time to commit.