[IPOL discuss] Ipol articles class + an example

[Nicolas Limare]

Hi,

> I think we should rule out the use of two columns, a classic solution,
> because it is not comfortable on the web. Then, we can change
> the margins and the paper size. The three variants proposed are:
> 1) The same margins as before in A4 paper.
> 2) The second option is to reduce the margins so as to get about 80 cpl.
> 3) The last option is to use A5 paper.
> What do you think?

I agree with the exlusion of columns. I feel the 2nd solution is the
most comfortable to read, and the margins are not a problem for
me. Why would it be more a problem when the PDF in embedded in an HTML
page than viewed in a PDF reader?

> > * 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?
> 
> This was a suggestion by Jean-Michel Morel to give to the code
> and supplementary material a especial status, suggesting they
> are not optional but obligatory parts, particular to IPOL.

Why not, but I still think that only the DOI link should be used
there, ie no link to individual files and versions.

> I am quite sure that in many cases, going from the initial
> PDF version to the one that can be compiled on IPOL servers
> will not be straight forward. So we should provide an easy
> way in which the authors can upload their zip/tgz to test as many
> times as they need. Then, once they think the generated file is OK,
> the editor should only check that the format is satisfied. But this
> only implies checking the resulting PDF. Otherwise, it would be
> too much work.

Agreed. I can produce a web interface similar to http://tools.ipol.im/pkg/
where people upload a zip/tgz and get a pdf result with the LaTeX log.
This will require a few rules, like "how is the article file called".
I can work on it once the current discussion comes to a conclusion.

Should we support a BibTeX step in the LaTeX->PDF compilation?

> I agree that it would be nice to have well behaved LaTeX
> sources to be able to be re-compiled to new formats
> in the future. Unfortunately, I don't think this is possible.
> [...] I don't think we can rely on the possibility of re-compiling
> the articles in the future. As in any other journal, as format
> evolve, old and new articles will co-exist having different formats.

OK.

> Comments and suggestions are very appreciated.

I like how these new versions look.

Comments on the header:
- the IPOL logo is not correctly rendered by the Flash reader:
  http://dev.ipol.im/~simonl/php/pdfInHtml/FlexPaper/index.php?doc=../upload/docs/ipol_example2.swf
- "Image Processing On Line" could link to
  http://dx.doi.org/10.5201/ipol (DOI register for IPOL as a journal)
- CC-BY-NC-SA could link to
  http://creativecommons.org/licenses/by-nc-sa/3.0/

For the links:
- A quick idea: did you try to use the purple color from the logo (rgb
  0.357 0.286 0.651) for the links? It may look nice (or may not, it's
  just a quick idea...).

-- 
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/20120119/5c5c38bb/attachment.pgp>