[IPOL discuss] Ipol articles class + an example

Pierre Moulon pmoulon at gmail.com
Wed Jan 18 08:43:50 CET 2012


Just a general question:

On the test pdf we only see author names.
Do you think that affiliation must be written ?

Regards,
Pierre

2012/1/17 rafael grompone von gioi <grompone at gmail.com>

> Hi,
>
> I prepared a new version of the IPOL LaTeX class, incorporating
> most of Nicolas' suggestions. The class files and examples are here:
>
>  http://dev.ipol.im/~jirafa/ipol-latex-format/
>
> The main changes are the addition of the IPOL logo and
> reference at the beginning, and the links color. There are
> also three variants to cope with the problem of the number
> of characters per line:
>
> > 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 am well aware of this rule, but the compromise in our case is not easy.
> 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. The full page is used and
> this reduce the space wasted on the web page. The problem is that
> there are about 100 cpl and it is not nice to read. The line length rule
> is for continuous long reading, and IPOL articles are not to be
> read as a novel. The reading quality of the LaTeX articles should be
> far better than the current HTML version. So, the first option is to pay in
> long lines this compromise.
>
> 2) The second option is to reduce the margins so as to get about 80 cpl.
> The result is intermediate. The margins are better for a printed article,
> but worse for a web page, and the lines (even if still long) are far better
> than in option 1.
>
> 3) The last option is to use A5 paper. The length of the lines is optimal,
> about 67 cpl. The page size may be even better than A4 for web reading.
> The compromise is not so clear for printing. Printing two pages per paper
> sheet produce a reasonable printed size without wasting paper. I think the
> result is even better than the previous two options. However, it is an
> uncommon paper size and it can confuse some people.
>
> What do you think?
>
> Please note that the commands defined by the LaTeX class changed
> from the previous version. There is no longer a command to produce
> the title; it is always generated after the IPOL logo and reference.
> The user must only define the title and authors with a command.
>
> > * 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.
>
> > 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.
>
> I think it is now clear that the initial submission should be on any
> PDF format, as long as the editors and reviewers can read it.
>
> I agree too that the final PDF should be generated in
> IPOL server, so we have the sources, we can generate
> different quality/file size versions, and eventually we could
> generate new versions on the future. But there are two
> important points to discuss:
>
> 1) The procedure.
>
> 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. People sometimes uses particular
> packages, and adapting the figures and tables to IPOL format
> can take considerable time. I think this work must be done by
> the authors. First using our LaTeX package and guidelines in their
> own machines and then in our server. 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.
>
> 2) Future compilation of LaTeX files
>
> 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.
> We know already how much work it is needed to produce
> C programs that satisfy a standard and that probably
> we will be able to compile in the future. The problem is
> worst for LaTeX: there is no real standard and we need
> to use many packages developed by many different
> people and different quality level. Moreover, we can ask
> the authors to do the standardization effort on the code
> because it is the essence of IPOL, but there is no point
> in asking the same effort for the LaTeX files. The PDF
> version of the articles are the standard version we will
> surely have in the future.
>
> 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.
>
> Comments and suggestions are very appreciated.
>
> Best regards,
> rafael
> _______________________________________________
> discuss mailing list
> discuss at list.ipol.im
> http://tools.ipol.im/mailman/listinfo/discuss
>



-- 
Regards/Cordialement,
Pierre M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20120118/74edbdcd/attachment.html>


More information about the discuss mailing list