[Journal] About the Journal latex file and other though

[Daniel Ames]

It might be worth planning to keep the technical articles off of the SVN
until they've been peer reviewed, etc.  Notice that on the generic journal
page, I added some text noting for people to submit their technical articles
directly through the OJS site, rather than "adding their name" to the
journal WIKI page.  This should give the reviewers a little more confidence
that their review isn't just pro-forma, but actually will be used to help
determine which technial articles get published and when... - Dan

On Mon, Mar 31, 2008 at 2:47 PM, Tyler Mitchell (OSGeo) <tmitchell at osgeo.org>
wrote:

>
> On 13-Mar-08, at 2:22 PM, Yves Jacolin wrote:
> > I think it will better to find a standard way to named the LaTeX file.
> > Currently, the name of the author is used, following by the
> > filename which
> > always different and we never now in which directory it is, which
> > is sometime
> > hard to find out. It could be easier (for translator) to find out
> > the file if
> > it has a standard name, for exemple :
> > <thematic>/<topic>_<authorName>/<topic>_<authorName>.tex.
> > All other standard filename could be better.
>
> Hi Yves,
> Thanks for the feedback on these ideas - I appreciate the
> thoughtfulness.
>
> > <thematic>/<topic>_<authorName>/<topic>_<authorName>.tex.
>
> I agree with this approach for storing files in SVN.  As long as no
> one else has any concern about it, I would like to adopt this as a
> standard.  So, for example, an entry might look like this:
>
> /journal/volume_1/en-us/case_studies/mapserver_mitchell/
> mapserver_mitchell.tex
>
> > It seem important to me that it should avoid to let some extra tex
> > or other
> > files not useful in the svn. It is possible to delete this kind of
> > file as
> > soon they are not useful. Translator will not translate wrong files ;)
>
> Agreed.  Each editor will need to be responsible for their own
> folders to make this happen.
>
> > Another though, if you can send an email to the list as soon as a
> > new tools is
> > used for the journal, it could be great. We began to work to the
> > splitted pdf
> > file and someone find the nice tools in final_pdf/ directory ;)
>
> Funny you should mention that, because I forgot about that file and
> am not even sure if I used it in the end (I wrote it in an airport
> lobby somewhere).  For those of you who haven't noticed how we do the
> final separate PDFs for each article, you can see this simple script
> that helps to break apart the main PDF, add a cover, add the credits
> and create a new file.
>
> http://svn.osgeo.org/osgeo/journal/volume_3/en-us/final_pdfs/
> make_pdfsplit.sh
>
> > Finally, it seem important to me that each article in the
> > OSGeo_journal.tex
> > file have to be separate by a \newpage:
>
> I'm not opposed to this idea, and I will try it with the next volume
> to see how it looks.  I've struggled with this on and off because
> that documents have had a lot of pages already - by adding new page
> breaks it could easily have added 10 more pages to the previous
> issues.  I thought reducing this might help reduce paper printing
> costs (for those printing the PDF) - but in this day I think we can
> put the responsibility back on the reader to decide the best approach
> for printing.  I've used the latex module "savetrees" before and it
> helps suck out unneeded space - having a "minimised" version like
> this would be a nice option.
>
> Thanks again for the feedback!
> Tyler
> _______________________________________________
> newsletter mailing list
> newsletter at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/newsletter
>



-- 
Daniel P. Ames, PhD, PE
Geospatial Software Lab
Department of Geosciences
Idaho State University - Idaho Falls
amesdani at isu.edu
www.hydromap.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/newsletter/attachments/20080331/da31f295/attachment.html