I use Xournal for pdf-annotating at university lectures.
The more pages the pdf, the more annotations in the xoj-file will add up.
E.g. pdf-File: 140pages, corresponding xoj-file-size (with annotations): 2MB - after opening: 500MB RAM-usage and painstakingly slow at page size scaling (unusable when you have to take notes quickly).
I had hoped with the function "pdf page loading just in time" in the config-file this problem would not occur.
The difference between the the two options (true/false) is not too big in my system.
It seems to load all the pages/notes first before being ready. This would be fine enough, but every scaling attempt will be answered after about 10 sec. My notebook is not the fastest (1,5GHz Dothan) but I believe the handling of files with a good deal of annotation is very inefficient in the first place.
Any way out of it (without file splitting) ?
Any help would be very much appreciated. Thanks
Yes, all the annotations are loaded into memory - the "progressive backgrounds" option only applies to bitmap renderings of PDF pages, not to the annotations in the xoj file themselves. (Mind you, this still speeds things up by several orders of magnitude).
I agree it'd be much faster if the annotations on invisible pages could be processed faster at loading and rescaling. This is an issue with the libgnomecanvas architecture - it's just not suitable for very large documents.
I'll try to think about what could be done, but my expectation is that the different architecture in Xournal++ (which doesn't depend on libgnomecanvas) will make it easier to fix this issue. In the meantime, the only solution is probably to split the annotations into different xoj files…
Thanks for the reply.
Splitting the pdf-file first and then annotating them consequently was the first thing that came to my mind and it works best.
Next idea was: when scaling becomes too slow then print to pdf and use this pdf.pdf as backround for annotating e.g. the next 50 pages. Works indeed very well (its damn fast). But if you want to edit something in the first pages you have to print to pdf again, e.g. twice if the editing shall appear in pdf.pdf.pdf as well, possible but confusing. Would it be possible to load a xoj-file with all the annotations but edible only on the visible page? That would be similar to the pdf.pdf.xoj-effect.
libgnomecanvas architecture - oh, well, I don't know anything about that. And what's the "++" version/architecture?
I guess Xournal++ is the following version to 0.4.5 and can be obtained from SVN repos but has to be compiled by oneself?
I'm afraid to ask you again for helping me out as to where to find short information about SVN, CVS and what it actually means.
BTW, I tried Jarnal instead but the Look&Feel is clearly behind Xournal (speed, ink resolution, menus).
Did I just write "edible" annotations? Not too bad, but I meant "editable" ;)
Well, coming to that, are these posts here editable? I couldn't find the usual "edit" button.
Thanks! Just to clarify: xournal as it exists currently relies on a library called libgnomecanvas to handle the placement of graphical objects (page background, text items, pen strokes, etc.) on the screen. So the entire xoj file (minus PDF backgrounds of pages that haven't been viewed when in progressive mode) gets loaded into memory, converted into libgnomecanvas objects, and the library takes care of displaying everything.
Xournal++ is a code rewrite in C++ by Andreas Butti, which does not use libgnomecanvas but rather does the drawing itself (this is just one of many differences between the two versions). It is not quite yet in final stable form, though it has made a lot of progress; so I wouldn't necessarily recommend using it for actual work if you don't want to risk losing data.
There will most likely be another release of xournal after 0.4.5, when I find the time and courage to do it, but it'll be a minor incremental update and will not include any serious rewrites so it won't address the issue at hand. Xournal++ versions will start with a different numbering (most likely, strictly higher than 0.4.x) but the first public release isn't quite there yet.
CVS and SVN repositories are online source code archives; to the casual user the main difference is that the code is downloaded using different commands. The latest xournal version (= 0.4.5 plus various bugfixes and minor patches) is in a CVS repository, while Xournal++ lives in a SVN repository. In both cases, after downloading the code it needs to be compiled and installed.
to download the code:
cvs -d:pserver:firstname.lastname@example.org:/cvsroot/xournal login
cvs -z3 -d:pserver:email@example.com:/cvsroot/xournal co -P xournal
to compile: in the main directory where the code was downloaded,
1) ./configure (if it complains, install any missing development packages: gtk2-devel, libgnomecanvas-devel, poppler-glib-devel, then run configure again)
2) make (this compiles the source code and produces an executable binary in src/xournal)
3) make install (as root) (this copies all the necessary files into /usr/local/bin so you can use it; your distribution's version is in /usr/bin unless you have previously uninstalled it).
For xournal++, the first step is to get the SVN code by running
svn co https://xournal.svn.sourceforge.net/svnroot/xournal xournal
then configure, make; given that it's not completely stable yet, you might want to test it thoroughly before doing "make install".
Hey Denis, thanks for taking the time to explain. Looks a bit complicated to me, but you gave me an excellent starting point.
I've have Xournal installed from the Debian Wheezy repositories. So I'm using Xournal 0.4.5 without the "various bugfixes and minor patches" that are included in the CVS version. Before I try to compile/install the CVS version (in order to get rid of the above mentioned bug) I need to know if the xoj-files from either version are compatible among each other. Thanks.
The CVS version is very close to the basic 0.4.5, and is definitely compatible in terms of file format (in both directions). However, I don't think it will solve your issue with memory usage in any way - none of the minor changes concern this.
Xournal++ is more different; it is backwards compatible in that it reads Xournal files, and I believe if you don't insert images it is also compatible in that xournal can read its files; but you should double-check. However, xournal++ is not yet a stable release, so I would not recommend working with it on a regular basis as there may be frequent crashes - or else, save your work often, and keep backup copies of files in case they ever get corrupted.
Sorry, I thought I had put my last post into the "Bluetooth crashes Xournal"-thread. I intended compilation of the CVS version in order to (hopefully) eliminate the hanging stylus problem. Memory consumption is slowing down Xournal but was not the issue I wanted to solve by that. My mistake.
Thanks for helping me with the compatibility question.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.