[IPOL discuss] Ipol articles

[Simon Loic]

Thanks all for your feedback. Please if you report a problem, click on the
"get link" button and provide the produced URL so that we can observe the
issue as well :).

Jose Luis, I understand your reservation: why bother to create a pdf viewer
when there are so many of
them (e.g. the Adobe Acrobat) freely available? In fact, the first
embedding solution can use the Adobe plugin if you have it installed. The
reason why we tried alternatives was with respect to users that would not
have a plugin installed.

I agree with Nicolas' preferences among the 3 embedding solutions but I
wish we had more opinions on that matter. One issue with pdfjs also, you
can not select text and copy/paste it. But pdfjs is under development, so
that might be fixed some day. I also agree that we should try in the same
page layout as current Ipol articles, with the 3 tabs, etc. Though I don't
know how to do that. Nicolas, can you help me on this?

As Jean-Michel pointed out, we agreed that Latex+pdf was a must-have for
the sake of the authors comfort and more importantly the fact that pdf are
a natural way to distribute papers (think of google scholar and the like).

Now Jose Luis is right about the many advantages of an html rendering of
the article. But then I don't think the pdf produced by Nicolas is
acceptable. Personally I'd rather have a nice pdf generated with Latex
(that will be embedded in the web site and available for download), than a
nice html article associated with a bad quality pdf.

This said, rephrasing what Rafael has already mentioned, it is still
possible to impose more restrictions on the latex file to be able to
generate both a pdf and html. But this would require much more trial and
error effort. Another possible way is to let the authors free to produce
any latex and then have someone responsible to adapt it manually to a
wiki+mathjax. Well, to be honest I hope that guy won't be me...

We have to face a choice, that apparently cannot be much delayed: shall we
give the green light for latex submissions? Here my two cents on how we
could handle the situation, given its emergency. I support Latex
submissions so that current authors can forget about the wiki language.
Then we can soon enough provide them the Ipol class. Until a better
solution is found to render the article on the Ipol web site, we can embed
the pdf with one of the three solutions proposed so far (or as Nicolas
suggested with a combination of them) and have a download link.

This way we would have a system that is in my opinion rather satisfying,
since usually only pdfs are distributed by scientific journals. Besides, we
can evaluate how bad (or let be optimistic, how good) pdf embedding work
with ipol articles and decide at leisure on the necessity of another
solution.

Happy new year!
--
Loïc


On Fri, Dec 30, 2011 at 3:44 PM, rafael grompone von gioi <
grompone at gmail.com> wrote:

> Dear all,
>
> I have some comments about the Ipol LaTeX class:
>
>
> - First, the example presented is not intended to be
> the guide to authors nor an example complementary
> to this guide. We present it just to give an example for
> this discussion. We may eventually decide to use such
> an example as a complement to the authors article guide,
> and in such case we should modify it to be sure it includes
> all the typical structures to be present in an article. For
> example, in the example figures and algorithms have
> no caption, there is no table, etc. Once we agree on the
> form for the articles, we should write the author guide,
> hopefully as good as the software guide and maybe
> provide an article example.
>
>
> - There are roughly two approaches we can take:
>
> 1) Impose a lot of restrictions to keep a lot of control
> on the articles so we would be able to change the
> format or maybe even convert them to html in the
> future.
>
> 2) Specify a format: paper size, margins, font and
> font size, header, etc., and let the authors prepare
> the pdf without restrictions on the LaTeX source.
>
> There are, of course, mixes of these two approaches.
>
>
> - 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. But the
> authors can use the class or not, provided that the format is
> respected. The LaTeX class does the minimum, and most
> things are handled in the usual LaTeX way and the
> author can use any package needed. The author would
> generate the PDF and Ipol editors would only verify the
> restrictions and keep the sources, but without a guarantee
> that we would be able to compile it again (at least in a
> simple way).
>
> This is the usual procedure in journals, except that
> in some cases the editorial team prepares the final
> article from the sources. But once the PDF is generated,
> it is fixed and would not change again. It is usually
> accepted that the authors verified every detail, and even
> typographical details or changing the format is
> not allowed afterwards.
>
> The main advantage of this approach is simplicity.
> The authors have freedom, we don't have to build
> a complex LaTeX class and solve all possible problems,
> and we don't have much editing work.
>
>
> - A restricted approach has many advantages, certainly.
> But it needs a development period until we manage
> to have an LaTeX class not too restrictive so authors
> can prepare the articles as they are used to, and that
> it works well in different and evolving systems,
> and guaranteeing that we would be able to compile
> in the future.
>
> 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. 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.
>
>
> - The Ipol LaTeX class we proposed is as simple as
> possible. I know enough about TeX/LaTeX to know
> I don't know enough. The proposed class only
> uses plain LaTeX, is derived from the "article" class,
> and sets the papers size, margins, font size and header,
> and little more. It was made using standard commands.
> I preferred to create a new command instead of modifying
> existing ones; a modification must be much more careful
> and needs maintenance. The class only affects some
> aspects. But all other things must be handled as in
> any LaTeX documents: equations, labels, figures,
> tables, etc. A priori there is no restriction for authors
> to use any package or LaTeX methods they like.
>
>
> - 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.
>
>
> - We could include IPOL logo, I will make some
> experiments.
>
>
> - About the CamelCase, names like \ipolSetYear,
> I agree that is more common in LaTeX to use
> names like \ipolsetyear. But I think it is hard to read
> and prefer \ipolSetYear. But we can change it if
> you prefer.
>
>
> - 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.
>
>
> - I don't like the links colors schema, I will try to
> find a new one to propose.
>
>
> Best regards,
> rafa
> _______________________________________________
> discuss mailing list
> discuss at list.ipol.im
> http://tools.ipol.im/mailman/listinfo/discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20111231/6ced5382/attachment.html>