Indeed, after pointing Xournal++ to my checkout of poppler, compilation went smoothly!
I'd be willing to help test, let me know what you need. -rhl On Tue, Apr 19, 2011 at 2:50 AM, <xournal-devel-requ...@lists.sourceforge.net> wrote: > Send Xournal-devel mailing list submissions to > xournal-devel@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/xournal-devel > or, via email, send a message with subject or body 'help' to > xournal-devel-requ...@lists.sourceforge.net > > You can reach the person managing the list at > xournal-devel-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Xournal-devel digest..." > > > Today's Topics: > > 1. Re: Xournal++ State (Andreas Butti) > 2. Re: Xournal++ State (Michael J Gruber) > 3. Re: collaborative xournal (Jonathan R Young) > 4. Re: collaborative xournal (Andreas Butti) > 5. Re: Xournal++ State (Bob McElrath) > 6. Re: Xournal++ State (Michael J Gruber) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 18 Apr 2011 17:12:16 +0200 > From: Andreas Butti <andreasbu...@gmail.com> > Subject: Re: [Xournal-devel] Xournal++ State > To: Michael J Gruber <michaeljgruber+gm...@fastmail.fm> > Cc: xournal-devel@lists.sourceforge.net > Message-ID: <4dac54d0.1080...@gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > >>>> Regarding Images: >>>> Having the option to not attach them (just like backgrounds) would be >>>> really nice, with an element like: >>>> >>>> <image left="74.00" top="278.00" right="595.28" bottom="799.28" >>>> filename="bg_1.png"/> >>> why? >>> >>> The Image format I use is 100% compatible with the pach which is >>> available for Xournal on sf.net >> It's good to have it compatible (though that patch never made it into a >> released version), but still the extension with 'filename=""' would not >> break it. > > Are you sure? Try it out;-) > > Xournal has for reading always a loop which checks every attribute, if > you have an attribute more it don't read the whole file. > > That's the reason why I leave everything exactly the same. (Even if you > change the order of attributes it don't read the files any more). > > For me personal I said I leave it in the first release 100% compatible > with Xournal (and optional with the image patch). And if all is working, > the next release will use a new fileformat which is not compatible, but > contains resources and new features. > > (based on ZIP instead of GZip) > >> Not attaching images is important because of file size, especially, but >> not only when you include the same image several times. I would say it's >> important for the same reasons out which backgrounds can be attached or >> detached. > This is an argument for using attaching images... >> Also, imagine using a "library" of images that you include again and >> again, or a workflow where you regenerate the image and want your xoj to >> use the regenerated image automatically. > This is no argument for attaching images, this is in my opinion against, > because the data is may inconsistent. > > There is a Python API for Xournal++, which is not finished yet, and at > the moment only used for testing, but later you should write a Python > Plugin for this, so there is for sure no inconsistency. > >>> For future releases I'll create a new format (e.g. based on ZIP) which >>> can handle resources better. >>> >>>> BTW: xournalpp produced that 'filename="bg_1.png"' for the image >>>> background, but the filename is "wrong". But then it does find it on >>>> restart! Quite confusing. OTOH, the "resuse image" dialog for image >>>> backgrounds is great and just what I would love for detached image >>>> objects also :) >>> I'll check this, I don't understand what you mean now, but I didn't >>> really test background image yet;-) >> Journal -> paper background -> Image: select "bend.png" >> Save xoj. >> >> The xoj is: >> >> <?xml version="1.0" standalone="no"?> >> <xournal creator="Xournal++ 0.1" fileversion="2"> >> <title>Xournal document - see http://xournal.sourceforge.net/</title> >> <preview>...</preview> >> <page width="22.00" height="31.00"> >> <background type="pixmap" domain="attach" filename="bg_1.png"/> >> <layer/> >> </page> >> </xournal> >> >> Different filename. But when I close and reopen xournalpp finds it or >> rather: I see now that there is a copy >> >> 2011-04-18-Note-15-07.xoj.bg_1.png >> >> in my workdir. Is that (copying background images) how it works with >> xournal trunk? > On the open dialog is a checkbox, "Attach to Xournal". Even on my > application (but in Xournal++ it's may not working correct;-)) > > I'll may do the same for insert images. > > Andreas > >> Michael > > > > ------------------------------ > > Message: 2 > Date: Mon, 18 Apr 2011 15:16:01 +0200 > From: Michael J Gruber <michaeljgruber+gm...@fastmail.fm> > Subject: Re: [Xournal-devel] Xournal++ State > To: Andreas Butti <andreasbu...@gmail.com> > Cc: xournal-devel@lists.sourceforge.net > Message-ID: <4dac3991.80...@fastmail.fm> > Content-Type: text/plain; charset=ISO-8859-1 > > Andreas Butti venit, vidit, dixit 18.04.2011 12:41: >> >> >> Am 18.04.2011 11:32, schrieb Michael J Gruber: >>> Andreas Butti venit, vidit, dixit 31.03.2011 19:06: >>>> Hello >>>> >>>> I'm still working on a new release, I did some re-factoring: >>> ... >>>> And there are also some things not working with "make install", if >>>> somebody has time or good knowledge of autotools I would appreciate some >>>> help;-) >>> Ciao Andreas, >>> >>> what's the best way in which we can help (besides autotools)? It seems >>> that there's no point investing in xournal (non-pp) any more, code-wise. >>> So, since I'm very interested in getting image inclusion, I'm forced to >>> look at xournalpp... >> >> Are you a developer? (You don't know Autotools either?;-)) > > C, not really C++. No autotools... > >> Else: Testing... As you did. > ... >>> Regarding Images: >>> Having the option to not attach them (just like backgrounds) would be >>> really nice, with an element like: >>> >>> <image left="74.00" top="278.00" right="595.28" bottom="799.28" >>> filename="bg_1.png"/> >> why? >> >> The Image format I use is 100% compatible with the pach which is >> available for Xournal on sf.net > > It's good to have it compatible (though that patch never made it into a > released version), but still the extension with 'filename=""' would not > break it. > > Not attaching images is important because of file size, especially, but > not only when you include the same image several times. I would say it's > important for the same reasons out which backgrounds can be attached or > detached. > > Also, imagine using a "library" of images that you include again and > again, or a workflow where you regenerate the image and want your xoj to > use the regenerated image automatically. > >> For future releases I'll create a new format (e.g. based on ZIP) which >> can handle resources better. >> >>> BTW: xournalpp produced that 'filename="bg_1.png"' for the image >>> background, but the filename is "wrong". But then it does find it on >>> restart! Quite confusing. OTOH, the "resuse image" dialog for image >>> backgrounds is great and just what I would love for detached image >>> objects also :) >> I'll check this, I don't understand what you mean now, but I didn't >> really test background image yet;-) > > Journal -> paper background -> Image: select "bend.png" > Save xoj. > > The xoj is: > > <?xml version="1.0" standalone="no"?> > <xournal creator="Xournal++ 0.1" fileversion="2"> > <title>Xournal document - see http://xournal.sourceforge.net/</title> > <preview>...</preview> > <page width="22.00" height="31.00"> > <background type="pixmap" domain="attach" filename="bg_1.png"/> > <layer/> > </page> > </xournal> > > Different filename. But when I close and reopen xournalpp finds it or > rather: I see now that there is a copy > > 2011-04-18-Note-15-07.xoj.bg_1.png > > in my workdir. Is that (copying background images) how it works with > xournal trunk? > > Michael > > > > ------------------------------ > > Message: 3 > Date: Mon, 18 Apr 2011 16:45:49 +0100 > From: Jonathan R Young <jonathan...@gmail.com> > Subject: Re: [Xournal-devel] collaborative xournal > To: Bob McElrath <b...@mcelrath.org> > Cc: xournal-devel@lists.sourceforge.net > Message-ID: <4dac5cad.3020...@googlemail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi - yes that is what I was thinking - basically build on the existing > frameworks for collaboration, rather than build an application specific one. > BTW - I am an IT architect, rather than a hard core developer (although > I occasionally dabble, and used to code years ago!) > Jonathan > > On 18/04/11 09:53, Bob McElrath wrote: >> No I think he means to encode individual strokes into SVG and transmit them. >> It's also then easy to synchronize just by looking at some stroke sequence >> number, in case a client is disconnected. I think it's quite a good idea. >> >> FYI I just pulled the xournalpp source and it doesn't build, due to a problem >> with Settings.cpp. >> >> Andreas Butti [andreasbu...@gmail.com] wrote: >>> This would be possible, but you cannot edit this again with Xournal. >>> >>> (SVG export is possible with copy paste or export in the current Xournal++) >>> >>> >>> But I don't support DBUS or such a protocol at the moment. >>> >>> (And I won't, no time...) >>> >>> >>> Andreas >>> >>> >>> Am 18.04.2011 09:38, schrieb Jonathan R Young: >>> >>> I wonder if Xournal could offer/consume a DBUS / telepathy / tubes >>> approach, perhaps using SVG as the transport format, so each completed >>> stroke can be published in realtime, and other clients can consume that >>> message and render it. >> -- >> Cheers, >> Bob McElrath [ Heidelberg University, Theoretical Physics ] >> >> "If you're not failing every now and again, it's a sign you're not doing >> anything very innovative." -- Woody Allen > > > > ------------------------------ > > Message: 4 > Date: Tue, 19 Apr 2011 08:04:15 +0200 > From: Andreas Butti <andreasbu...@gmail.com> > Subject: Re: [Xournal-devel] collaborative xournal > To: jonathan...@googlemail.com > Cc: xournal-devel@lists.sourceforge.net > Message-ID: <4dad25df.1060...@gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Am 18.04.2011 17:45, schrieb Jonathan R Young: >> Hi - yes that is what I was thinking - basically build on the existing >> frameworks for collaboration, rather than build an application specific one. > Can you make an example which framework should be used? > (And why?) > >> BTW - I am an IT architect, rather than a hard core developer (although >> I occasionally dabble, and used to code years ago!) > Ok, then you can draw an UML component diagram or something like this=) > > > (I passed my apprentice as "Applikationsentwickler" successfully, and > I'm studying computer science, now in the 4th semester) > > Andreas >> Jonathan >> >> On 18/04/11 09:53, Bob McElrath wrote: >>> No I think he means to encode individual strokes into SVG and transmit them. >>> It's also then easy to synchronize just by looking at some stroke sequence >>> number, in case a client is disconnected. I think it's quite a good idea. >>> >>> FYI I just pulled the xournalpp source and it doesn't build, due to a >>> problem >>> with Settings.cpp. >>> >>> Andreas Butti [andreasbu...@gmail.com] wrote: >>>> This would be possible, but you cannot edit this again with Xournal. >>>> >>>> (SVG export is possible with copy paste or export in the current Xournal++) >>>> >>>> >>>> But I don't support DBUS or such a protocol at the moment. >>>> >>>> (And I won't, no time...) >>>> >>>> >>>> Andreas >>>> >>>> >>>> Am 18.04.2011 09:38, schrieb Jonathan R Young: >>>> >>>> I wonder if Xournal could offer/consume a DBUS / telepathy / tubes >>>> approach, perhaps using SVG as the transport format, so each completed >>>> stroke can be published in realtime, and other clients can consume >>>> that >>>> message and render it. >>> -- >>> Cheers, >>> Bob McElrath [ Heidelberg University, Theoretical Physics ] >>> >>> "If you're not failing every now and again, it's a sign you're not doing >>> anything very innovative." -- Woody Allen >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Xournal-devel mailing list >> Xournal-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xournal-devel > > > > > ------------------------------ > > Message: 5 > Date: Tue, 19 Apr 2011 01:43:36 -0500 > From: Bob McElrath <b...@mcelrath.org> > Subject: Re: [Xournal-devel] Xournal++ State > To: Andreas Butti <andreasbu...@gmail.com> > Cc: xournal-devel@lists.sourceforge.net > Message-ID: <20110419064336.gb13...@mcelrath.org> > Content-Type: text/plain; charset=us-ascii > > I used xournal++ for a few hours yesterday to test, here are some notes/bugs > about it: > > 1) Using rectangle select as middle mouse button (pen button) doesn't work. > > 2) Undo seems to redraw in 2 steps, separated by a second or two, and a crash > always soon follows. > > 3) The Autosave/restore needs a UI. > > 4) After strokes are drawn they are re-drawn, it appears with slightly > different > width or anti-aliasing. > > 5) Toolbar edit (great!!!!) drag & drop to toolbars doesn't work. > > 6) Adding toolbar handles and letting the user drag them would be a better UI. > > 7) All the different types of toolbars needs to be cleaned up... > > 8) The added grey borders are not useful, IMHO it's just wasted screen space. > Also the red border around the active page is not needed, I think. I assume > this is because you want to know which page is "active" for e.g. pasting. I > never had any trouble with xournal this way. > > 9) Initial zoom is giving me a page much smaller than my screen (this could be > partially the X server's fault) > > 10) Some UI elements are now focusable with the keyboard (e.g. zoom slider). > Long ago I submitted a patch that made all UI elements send focus back to the > canvas so that the arrow keys on the bezel of tablet pc's would always scroll > the page instead of e.g. changing the zoom when a UI element is focused. > > 12) The "very fine" pen has been removed. The finest pen is too fat for my > taste. > > 13) Memory usage is drastically reduced. That's FANTASTIC. > > Great work Andreas! Let's get this thing into a release-able state! > > -- > Cheers, > Bob McElrath [ Heidelberg University, Theoretical Physics ] > > "If you're not failing every now and again, it's a sign you're not doing > anything very innovative." -- Woody Allen > > > > ------------------------------ > > Message: 6 > Date: Tue, 19 Apr 2011 08:49:46 +0200 > From: Michael J Gruber <michaeljgruber+gm...@fastmail.fm> > Subject: Re: [Xournal-devel] Xournal++ State > To: xournal-devel@lists.sourceforge.net > Message-ID: <4dad308a.1060...@fastmail.fm> > Content-Type: text/plain; charset=ISO-8859-1 > > Andreas Butti venit, vidit, dixit 18.04.2011 17:12: >> >>>>> Regarding Images: >>>>> Having the option to not attach them (just like backgrounds) would be >>>>> really nice, with an element like: >>>>> >>>>> <image left="74.00" top="278.00" right="595.28" bottom="799.28" >>>>> filename="bg_1.png"/> >>>> why? >>>> >>>> The Image format I use is 100% compatible with the pach which is >>>> available for Xournal on sf.net >>> It's good to have it compatible (though that patch never made it into a >>> released version), but still the extension with 'filename=""' would not >>> break it. >> >> Are you sure? Try it out;-) >> >> Xournal has for reading always a loop which checks every attribute, if >> you have an attribute more it don't read the whole file. > > That's not good. It should ignore that element only. Does it ignore > unkown elements? > >> >> That's the reason why I leave everything exactly the same. (Even if you >> change the order of attributes it don't read the files any more). > > Uh. XML parser anyone? ;) > >> For me personal I said I leave it in the first release 100% compatible >> with Xournal (and optional with the image patch). And if all is working, >> the next release will use a new fileformat which is not compatible, but >> contains resources and new features. >> >> (based on ZIP instead of GZip) > > What is the advantage of ZIP over GZip? > > On compatibility: I noticed that for a file "foo.xoj", xournalpp > suggests "foo.xoj.pdf" for the exported pdf while xournal suggests > "foo.pdf". Is that change intentional? > >>> Not attaching images is important because of file size, especially, but >>> not only when you include the same image several times. I would say it's >>> important for the same reasons out which backgrounds can be attached or >>> detached. >> This is an argument for using attaching images... >>> Also, imagine using a "library" of images that you include again and >>> again, or a workflow where you regenerate the image and want your xoj to >>> use the regenerated image automatically. >> This is no argument for attaching images, this is in my opinion against, >> because the data is may inconsistent. > > I want it up to date with regenerated images in this case. Because that > would be the "consistent" state in some use cases. > > I'm not arguing for a different default; I'm just claiming that there > are use cases where you want to stay the image or background in the > state from the time of inclusion and other use cases where you want an > image or background to follow the state of a referenced file (like > xournal's defaulft for annotated pdf's). > >> >> There is a Python API for Xournal++, which is not finished yet, and at >> the moment only used for testing, but later you should write a Python >> Plugin for this, so there is for sure no inconsistency. >> >>>> For future releases I'll create a new format (e.g. based on ZIP) which >>>> can handle resources better. >>>> >>>>> BTW: xournalpp produced that 'filename="bg_1.png"' for the image >>>>> background, but the filename is "wrong". But then it does find it on >>>>> restart! Quite confusing. OTOH, the "resuse image" dialog for image >>>>> backgrounds is great and just what I would love for detached image >>>>> objects also :) >>>> I'll check this, I don't understand what you mean now, but I didn't >>>> really test background image yet;-) >>> Journal -> paper background -> Image: select "bend.png" >>> Save xoj. >>> >>> The xoj is: >>> >>> <?xml version="1.0" standalone="no"?> >>> <xournal creator="Xournal++ 0.1" fileversion="2"> >>> <title>Xournal document - see http://xournal.sourceforge.net/</title> >>> <preview>...</preview> >>> <page width="22.00" height="31.00"> >>> <background type="pixmap" domain="attach" filename="bg_1.png"/> >>> <layer/> >>> </page> >>> </xournal> >>> >>> Different filename. But when I close and reopen xournalpp finds it or >>> rather: I see now that there is a copy >>> >>> 2011-04-18-Note-15-07.xoj.bg_1.png >>> >>> in my workdir. Is that (copying background images) how it works with >>> xournal trunk? >> On the open dialog is a checkbox, "Attach to Xournal". Even on my >> application (but in Xournal++ it's may not working correct;-)) > > Sure, but "attach" does something different from what I expected. My > fault... There are 3 ways in which an image (inserted or background) or > pdf (annotated or background) can be treated: > > A) refer to (relative or absolute) location (include path in xoj) > B) include in xoj (as encoded content of an element) > C) copy file to foo.xoj.<special ending> and refer to that > C') derive a rendered version and apply C to that > > I wasn't aware of C until yesterday and thought "attach" does B. xournal > does this with "not attached" (checkbox not checked): > > annotated pdf: A, e.g. > <background type="pdf" domain="absolute" filename="/tmp/a/bend.pdf" > pageno="1" /> > > background png: A, e.g. > <background type="pixmap" domain="absolute" filename="/tmp/a/bend.png" /> > > background pdf: C', e.g. > <background type="pixmap" domain="attach" filename="bg_1.png" /> > with a rendering of the pdf in <xojname>.bg_1.png > > I'm really wondering why it's doing that (rather then referring to the pdf). > > With the "attach" checkbox checked, xournal does: > > annotated pdf: C, e.g. > <background type="pdf" domain="attach" filename="bg.pdf" pageno="1" /> > with a proper copy of the pdf > > background png: A, e.g. > <background type="pixmap" domain="absolute" filename="/tmp/a/bend.png" /> > > background pdf: C', e.g. > <background type="pixmap" domain="attach" filename="bg_1.png" /> > with a rendering of the pdf in <xojname>.bg_1.png > > That is, the "attach" checkbox does not even seem to work for > backgrounds, and xournal always does C' (attach a rendered png) for > pdf-backgrounds and A (refer to original png) for png-backgrounds. > > With the image patch for xournal, early version would do A and later > versions would do B. > > Given that situation, I'm not sure that compatibility would be the best > goal here... But in fact (and no matter what to do with the non-working > background-attach option), to be as compatible and consistent as > possible, xournalpp should never do B (xournal never did B), and > inserted images should do C (by default)! As a positive side effect, the > xml machinery would not have to deal with large binary-to-text-encoded > blobs. Also, implementing A as an option for inserted images would be > simpler then. I think the B-doing patch for xournal really lead us on a > wrong path in this respect. > > Michael > > > > > ------------------------------ > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > > ------------------------------ > > _______________________________________________ > Xournal-devel mailing list > Xournal-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xournal-devel > > > End of Xournal-devel Digest, Vol 17, Issue 3 > ******************************************** > ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
