Hi Landon, <br>
<br>
My two bits, others can pipe up too, but I warn you that I'm probably more open to non-latex options than others here... <br>
<br>
Short answer: scribus won't help, don't waste your time. What you did looks good but we can't switch to such a WYSIWYG "workflow".<br>
<br>
Long answer:<br>
<br>
It's an annual question brought up on this list and those interested can
search the archives for previous debate. I guess we need a wiki page
to keep these arguments on so it's clear. But Landon, you were even
part of this question last year, so you already know the positions.<br>
<br>
I have gone from knowing nothing about latex to being able to do the
entire workflow now (though bibliographies are haunting me a bit) - if I
can learn it, than you can too and with your programming experience you
can be even better than me, I'm sure!<br>
<br>
Scribus is (admittedly) not well suited for doing documents like our Journal length of 60+ pages.<br>
http://wiki.scribus.net/canvas/Category:FAQ#Books notes a few of the challenges which are deal-breakers for us, plus here are some of my concerns just to remind us of what we're dealing with:<br>
<br>
1. Were you seriously proposing to manually place, edit and maintain 60+
pages of text (without footnotes or multi-level table of contents too)
?<br>
<br>
2. Why lock up all the data in a binary format? It makes it hard for
distributed editing and version control, among other things. It would
be fine if it were a one man show that never needed any scripting. But
here we have different people managing different sections - it makes no
sense.<br>
<br>
3. Seems you have some ideas for improving our layout/style - that's worth a discussion on its own, let's hear it!<br>
<br>
4. Having trouble converting to latex? You know you can learn it, but
perhaps learning it on a full blown volume of the journal is biting off a
bit more than you can chew. It's really not that hard one article at a time, and me and others are willing and able to pull together the master document.<br>
<br>Last night I was able to compile all the proceedings articles in about
1.5 hours, including importing some openoffice docs and hacking author
contributed tex files. I did all the compiling from the command line
on a remote server and that was over a 50 page PDF (and I was
experiencing a post-Christmas chocolate sugar crash! Command "w2l
-ultraclean input.odt" helped me a lot.) <br>
<br>
Did I hit bugs and problems? Yes, but coming to others for help, I
think, makes our journal team efforts stronger. Whereas moving to a
different platform, scribus in particular, makes us weaker. We've built our own little
knowledge base among our team and I'm grateful for that. Sure, it slows
us down to have to hunt down help - but what FOSS advocate doesn't like
having to work with others? ;-)<br>
<br>
Though it may feel like it sometimes, our use of latex isn't some
esoteric exercise. It's an industry standard and meets our needs very
well and I was one of the first to review various tool options and was convinced
by others on the list to stick with (and learn) the latex way. I
haven't seen any benefit to move (except when I hit a particularly
challenging bug and am short on time), so I don't support the idea to switch at all.<br>
<br>
Others are always welcome to continue the debate, but for me personally
it is a non-starter and a waste of time. I don't support switching,
especially in the middle of a critical issue that needs to get out
soon. More on the status of vol 8 in another note.<br>
<br>
Tyler<br>
<br>
----- Original Message -----<br>
From: Sunburned Surveyor <sunburned.surveyor@gmail.com><br>
Date: Monday, December 27, 2010 10:49 pm<br>
Subject: [Journal] Volume 8 Rebellion<br>
To: OSGeo Journal <newsletter@lists.osgeo.org><br>
<br>
> Journal Team:<br>
> <br>
> I decided to foment a bit of a rebellion with Version 8 of the Journal<br>
> by putting together a Scribus file that can be used to layout the<br>
> journal articles for conversion to PDF. The scribus file uses open<br>
> font files, the OSGeo color scheme, and tries to hold to the <br>
> Volume 7<br>
> style as much as possible. (One small exception is that I <br>
> changed the<br>
> section and article titles to green instead of black.)<br>
> <br>
> The Scribus file uses master pages, linked text frames, paragraph<br>
> styles and autmatic page numbers to make page layout quick and simple.<br>
> I converted one of the peer review objects to PDF using this Scribus<br>
> file. Both the Scribus file and the PDF file created from it are<br>
> attached. I did this on my work computer, and Scribus is still a<br>
> little buggy on MS Windows, so there is a page numbering <br>
> problem. I'll<br>
> try producing the PDF on my Linux box to see if this fixes the<br>
> problem. I'm also going to look into using the Python scripting<br>
> functionality of Scribus to automatically generate the total page<br>
> numbers shown at the bottom of the page.<br>
> <br>
> I know most of you guys are hardcore LaTex fans, but I find LaTex<br>
> working with LaTex is like getting major dental work without a pain<br>
> killer. If we can use Scribus for Journal layout it eliminates my<br>
> dependence on everyone else for LaTex work. This means I can <br>
> take care<br>
> of the post production work on the Journal sooner, which will <br>
> speed up<br>
> our publication cycle. I know it is hard for people to make time for<br>
> the LaTex conversion, which isn't a short task, and I think things<br>
> will go smoother if I can start using an open source tool for post<br>
> production that I am familiar with.<br>
> <br>
> Take a look at the attached files and let me know what you <br>
> think. If<br>
> this is going to be acceptable to the group I can work on converting<br>
> the reminaing peer review articles for Volume 8 to PDF using Scribus.<br>
> <br>
> Landon<br>
> <br>
> PS - I'm also going to work on an epub template for the Journal <br>
> when I<br>
> get some time.<br>
>