[IPOL discuss] Ipol articles class + an example

[Nicolas Limare]

Hi,

> - There are roughly two approaches we can take:
> 
> 1) Impose a lot of restrictions to keep a lot of control
> 2) Specify a format: paper size, margins, font and font size,
> header, etc.,
> - The proposal we made if of the second kind. We would
> impose the paper size, the font size, etc., and we provide
> a LaTeX class that produce these restrictions. [...]
> This is the usual procedure in journals, except that
> in some cases the editorial team prepares the final
> article from the sources.

OK, I understand better now. My only experience with a journal was
with an Elsevier publication, which provides a LaTeX class, a LaTeX
"camera-ready" style and a BibTeX style, and I thought this was he
usual method.

I am quite reluctant to publish PDFs provided by the authors, because
it feels like publishing the compiled programs without having the
source. We would be stuck to a format with very limited options for
future evolution.

> We could do something in the middle: allow any format
> for the initial submission, so if the article is rejected
> the effort wasn't too big; but impose restrictions for the
> final submission.

I think this is the good way. The initial submission could in fact be
done in any format as long as the editors and reviewers can read
it. Reviewers are used to PDF so a pdf file (no web page, no viewer)
could fit. But when a document is prepared to be published by IPOL, it
should be provided in source form and compilable into PDF on IPOL's
"document processing system" (see later).

> In any case, the final submission must be prepared by the authors,
> we cannot afford editors do the work of conversion. Authors should
> prepare a version that compiles in Ipol server, and the editors
> should only check this is the case.

Well, I thought the authors would upload their source to an IPOL web
page, where an program would automatically compile it into a PDF
document. The result would be a web page with the source and PDF,
available to the authors and editors. Basically we would only need to
upload a zip/tgz archive with everything required for the document
compilation and the article LaTeX file under a known name. If this
compiles with pdflatex in the current TeX setting of the IPOL server,
then it's OK and used for the publication. The could could also be
uploaded in the same system.

> - A very important point is the format: We used small margins and
> 12pt font size to make it easier to be read if the PDF is embedded
> on the web. This is not the best option for printing, as it would use
> more paper. We had in mind that Ipol articles are not supposed to be
> printed. What is your opinion? I think this is an important point to
> consider.

I think some people do print PDF articles for convenience, so this can
not be excluded. But if the only drawpack is to waste some paper, I
think it is not a major problem because on can always choose to print
two pages per sheet.

But I think that in the current configuration, the lines are too
long. This makes the paragraphs wide and short, and is somehow
uncomfortable to read.

In "The Elements of Typographic Style", Bringhurst writes: "Anything
from 45 to 75 characters is widely-regarded as a satisfactory length
of line for a single-column page set in a serifed text face in a text
size. The 66-character line (counting both letters and spaces) is
widely regarded as ideal." I think 66 characters per line may be too
short and the current 100cpl too long, maybe 80 cpl is possible with
more margins?

> - I agree that all links to Ipol must use the doi
> url. Do you think we should put a link in
> the header to the article? Maybe the doi number
> can be linked to the doi url.

Yes, it should. See also the official DOI display guidelines:
-> http://www.crossref.org/02publishers/doi_display_guidelines.html

I think the article header should have the clickable DOI reference
formatted as an URL and a very short text about the materials
available on ipol.im, something like

    Published in Image Processing On Line on YYYY-MM-DD.
    ISSN 2105-1232 (C) YYYY IPOL CC-BY-NC-SA
    This article is available online with supplement materials,
    implementation, datasets and demonstration at
    http://dx.doi.org/10.5201/ipol.YYYY.XXXXXXXX

About the copyright part, the current IPOL copyright info says that
the articles are "(C) IPOL" and licensed under the CC-BY-NC-SA
license. But no formal copyright transfer is currently done, and a
future author suggested that the articles could as well be "(C) the
authors", with the same license. I think he is right, this is
consistent with the copyright policy for the code and it does not
restrict IPOL rights to publish the articles.

> - I don't like the links colors schema, I will try to
> find a new one to propose.

I suggest to be minimal and not visually disturbing by only using a
dark color (dark blue) instead of black for active links. No
underline, no color box.

8<----------8<----------8<----------8<----------8<----------8<----------

I tried to convert an existing article to the LaTeX format. The IPOL
article converted is a simple one:
-> http://www.ipol.im/pub/algo/lmps_simplest_color_balance/
The result is online:
-> http://dev.ipol.im/~nil/tmp/lmps_simplest_color_balance.tar.gz

This tar/gzip archive contains the LaTeX code, the included images, 3
different pdf outputs, and the makefile and markdown code I used to
create the LaTeX code.

Some other questions appeared during the conversion:

* I thint the author names are too large.

* The copyright info doesn't need to be repeated in every page header;
  instead, I would prefer to have the article title and authors,
  except on the first page.

* What should we write in the "ipolAbstract" ? Why do we need an
  "ipolCode" and "ipolSupp"? Can't this information be written in the
  article body, like it is currently in the wiki/HTML articles?

* The default pdflatex settings keep the full resolution of the
  graphics included in the document, resulting in unnecessary heavy
  files; mine was 20 MB! Before publications, they should be filtered
  and downsampled. This can be done with ghostscript:
  
  for a printer-friendly resolution (downsized to 3 MB), 
  gs -dSAFER -dNOPAUSE -dBATCH -sOutputFile=$@ \
    -sDEVICE=pdfwrite \
    -dPDFSETTINGS=/printer \
    -dCompatibilityLevel=1.4 \
    -dEmbedAllFonts=true \
    -f input.pdf

  for a screen-optimized resolution (downsized to 500 KB), 
  gs -dSAFER -dNOPAUSE -dBATCH -sOutputFile=$@ \
    -sDEVICE=pdfwrite \
    -dPDFSETTINGS=/screen \
    -dCompatibilityLevel=1.4 \
    -dEmbedAllFonts=true \
    -f input.pdf

  Other fine-tuning options are available too.
  -> http://ghostscript.com/doc/current/Ps2pdf.htm

* Authors will need to update their habits of publishing multitudes of
  images in their IPOL articles. There is no "hide/show" option in a
  PDF. Tens of examples are really not comfortable. Very large images
  are also a problem in a PDF, because they are displayed in reduced
  size, and one can not easily extract the images to examine them in
  detail.

* The need to access the images directly is another argument to
  publish an HTML version, or at least the full LaTeX source.

PS: and for the CamelCase commands... it's just a question of personal
taste, so it doesn't really matter.

-- 
Nicolas LIMARE - CMLA - ENS Cachan    http://www.cmla.ens-cachan.fr/~limare/
IPOL - image processing on line                          http://www.ipol.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20120101/c8e1f7d4/attachment.pgp>