[IPOL discuss] Ipol article viewer + web page
Nicolas Limare
nicolas.limare at cmla.ens-cachan.fr
Sun Jan 1 12:30:33 CET 2012
> 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?
I tried to do it by using an article I recently converted to LaTeX/PDF
(see my previous mail). To use the usual IPOL article page odel, I
just downloaded the article page with
wget --convert-links http://www.ipol.im/pub/algo/lmps_simplest_color_balance/
and I removed everything not necessary: the "content" section, the web
statistics marker, and all the useless metadata.
I converted my pdf articles to flash with swftools. Then, instead of
the HTML article body, I inserted the PDF versions:
* some links to the PDF file, in 2 resolutions
<p>
PDF File:
<a href="./lmps_simplest_color_balance_lr.pdf">low-resolution (500 KB)</a>,
<a href="./lmps_simplest_color_balance_hr.pdf">high-resolution (3 MB)</a>
</p>
* then the PDF plugin code
<object data="./lmps_simplest_color_balance_hr.pdf#view=FitH&scrollbar=1&toolbar=1&navpanes=0"
type="application/pdf"
width="850px" height="1200px">
</object>
* then, in the PDF plugin code (between <object> and </object>), the
Flash plugin code; I dropped all the javascript code (useless for a
static website) and used a simple <object> code instead:
<object type="application/x-shockwave-flash"
width="850px" height="1200px">
<param name="movie" value="./FlexPaperViewer.swf" />
<param name="flashvars" value="SwfFile=./lmps_simplest_color_balance_hr.swf&FitWidthOnLoad=true&InitViewMode=Portrait&ViewModeToolsVisible=true&ZoomToolsVisible=true&NavToolsVisible=true&CursorToolsVisible=true&SearchToolsVisible=true" />
</object>
* then, in the Flash plugin code (between <object> and </object>), the
abstract of the article in pure HTML.
Theoretically, it would be possible to insert the JavaScript viewer
code in the Flash plugin code, then the pure HTML abstract in a
<noscript></noscript> block. But pdf.js was too complex for me, I
could not find how it is supposed to be used.
The result:
<p>
PDF File:
<a href="./lmps_simplest_color_balance_lr.pdf">low-resolution (500 KB)</a>,
<a href="./lmps_simplest_color_balance_hr.pdf">high-resolution (3 MB)</a>
</p>
<object data="./lmps_simplest_color_balance_hr.pdf#view=FitH&scrollbar=1&toolbar=1&navpanes=0"
type="application/pdf"
width="850px" height="1200px">
<object type="application/x-shockwave-flash"
width="850px" height="1200px">
<param name="movie" value="./FlexPaperViewer.swf" />
<param name="flashvars" value="SwfFile=./lmps_simplest_color_balance_hr.swf&FitWidthOnLoad=true&InitViewMode=Portrait&ViewModeToolsVisible=true&ZoomToolsVisible=true&NavToolsVisible=true&CursorToolsVisible=true&SearchToolsVisible=true" />
<p>Color balance algorithms attempt to correct underexposed images, or
images taken in artificial lights or special natural lights, such as
sunset. </p>
<p>...</p>
</object>
</object>
This page is available online[1]. Please try it with various browsers,
and compare it with the HTML version[2]. The code can be downloaded
and modified[3].
[1] http://dev.ipol.im/~nil/tmp/lmps_simplest_color_balance_www/.
[2] http://www.ipol.im/pub/algo/lmps_simplest_color_balance/
[3] http://dev.ipol.im/~nil/tmp/lmps_simplest_color_balance_www.tar.gz
Refs:
* PDFObject markup generator
-> http://pdfobject.com/generator.php
* PDF open parameters
-> http://www.adobe.com/devnet/acrobat/pdfs/pdf_open_parameters.pdf
* Embedding Flash
-> http://www.alistapart.com/articles/flashsatay
* Use FlashVars to pass variables to SWF files
-> http://kb2.adobe.com/cps/164/tn_16417.html
I tried with WinXP, Adobe Flash 11 and Adobe Reader X:
* Chrome 16
- the PDF file opens with the PDF viewer built in Chrome, with poor
subpixel rendering of the text
- when the Acrobat Reader is enabled, it is used to open the PDF
file, with better visual quality
- when this plugin is disabled, the PDF opens with the Flash
Flexpaper viewer
- when Flash is disabled, the HTML text is displayed
* Firefox 6
- the PDF file opens with Adobe Reader
- when this plugin is disabled, it fails to open the PDF with the Flash
Flexpaper, and it doesn't display the HTML alternative; blank page...
- when Flash is disabled, the HTML text is displayed
* Opera 11
- the PDF file opens with Adobe Reader
- when this plugin is disabled, the PDF opens with the Flash
Flexpaper viewer
- when Flash is disabled, the HTML text is displayed
* Internet Explorer 8
- the PDF file opens with Adobe Reader
- when this plugin is disabled, it fails to open the PDF with the Flash
Flexpaper, and it doesn't display the HTML alternative; blank
page, same as Firefox
- when Flash is disabled, the HTML text is displayed
* Safari 5
- the PDF file opens with Adobe Reader
- I could not find how to disable only one plug-in
- when Adobe Reader and Flash are disabled, the HTML text is displayed
-> The PDF/Flash/HTML cascade seems to work, but some details must be
fixed for Firefox and Internet Explorer
New remarks from this test:
* the first time we visit the web page, loading the 3MB pdf file is
slow; it takes ~20 seconds and during this time the browser provides
no feedback and the page seems empty; the low-resolution version
would be faster, but we must check the quality is satisfying
* we need to maintain some HTML text because the indexation of the
article pages in search engines (tr4aditional, not google scholar
etc) is based on HTML content
* we need a way to mention the author and editor name, instution and
email in the LateX document
* a table of content per article is useful too, to jump to the part of
the article you are interested in
* some work is needed to design how the non-PDF materials (code,
datasets, etc.) are to be displayed in the article web page.
> 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 do not feel there is such an emergency, there is a need to evolve
and this requires the time and effort to test the possible solutions
and chose the best. The only point of pressure I see is that the wiki
system is overloaded and slow, but this is not an editorial issue. I
think lots of points still need to be solved before we have something
usable. By pushing for a quick change, I'm afraid we will only have a
bad change.
In addition to my previous remarks, I also want to mention that once
we have no more wiki/HTML interface, there is a need for a new author
interface instead of https://edit.ipol.im/. How will they send their
articles to IPOL? How will they update their versions? How will the
reviewers access them? We can not use the current wiki system in PDF
mode by simply uploading huge PDF files and LaTeX sources and editing
the HTML code by hand, and I do not want to be the one who will have
to fix all the problems induced by such an abuse of the tool. We could
try external managers such as Open Journal System, but someone has to
install, configure, test and understand the editorial manager, and this
won't be possible overnight.
--
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/d732ad51/attachment.pgp>
More information about the discuss
mailing list