22 Sep
2010
22 Sep
'10
5:25 p.m.
Hi,
On Wed, Sep 22, 2010 at 16:01, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
On 09/22/2010 04:31 PM, Marius Dumitru Florea wrote:
> I take it that the current implementation outputs HTML, right? I'd like
> to have a preview mode which generates small images instead, snapshots
> of each page/slide, placed one after another horizontally, in a div with
> a scrollbar. Could it be done?
I disagree with this, at least for Word files. What you're describing is a
sort of widget similar to what Scribd used to do. They switched to HTML5 not
that long ago and I think the way they display content is the way to go. See
http://www.scribd.com/doc/30964170/Scribd-in-HTML5 for more details.
For long documents, what I did is to load the document in a hidden DIV and
have a small JS snippet to "pop open" that DIV and display the document in
the page where it might take a lot of space. It worked well.
Guillaume
On 09/22/2010 03:47 PM, Sergiu Dumitriu wrote:
> On 09/22/2010 12:31 PM, Marius Dumitru Florea wrote:
>> Hi devs,
>>
>> I'm going to create a macro for previewing office attachments. It's
main
>> usage will be:
>>
>> {{officepreview attachment="presentation.ppt"
filterStyles="true"/}}
>>
>> "officepreview" is a bit long for a macro name. "preview" is
shorter
but
>> is too generic and thus can be confusing.
"preview" could be the name
of
a more generic macro that previews any type of
attachment, based on its
mime type (so not just office documents).
"attachment" is the only required parameter. It is also a bit long, but
"file", which is shorter, is confusing. Some users might try to preview
office documents from their file system or from the web.
"filterStyles" is optional, and defaults to false.
Office preview component relies entirely on the office
importer
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
component. So when you preview an office document
you get the same
result as if you would import it in a wiki page.
The job of the office preview component is to:
* obtain an XDOM from the office importer
* change image references to point to temporary resources, rather than
attachments
* cache the result
* render the XDOM to XHTML rather than wiki syntax.
In this context, your request is more suited for the office importer
component. Now, the office importer generates images for presentation
slides (both "text" and "graphics" modes are available), but they
are
displayed using an in-line frame with links to next/previous slides. We
can improve this display, but the code will go in the office importer
module.
I replied too fast.. for presentations, the in-line frame is generated
by the office preview component. So yes, I can improve it, but we need
to agree on the desired/expected output for presentations.
Thanks,
Marius
Thanks,
Marius
>
>> The office preview macro will be just a wrapper for the office preview
>> script service. This means no decorations (e.g. borders, headings,
etc.)
>> will be added around the output of the
script service:
>>
>> {{velocity}}
>> {{html}}
>> $services.officepreview.preview($attachmentReference, $filterStyles)
>> {{/html}}
>> {{/velocity}}
>>
>> I'm not sure if the office preview macro should be a wiki macro or a
>> Java macro. One disadvantage for wiki macros is
>> http://jira.xwiki.org/jira/browse/XWIKI-4262 . This means that the
>> attachment string reference must be resolve before calling the office
>> preview script service. Currently there's no clean way to resolve a
>> reference relative to a given document in velocity so I would have to
>> use groovy which raises programming rights issue. Alternative we can
>> extend the
>>
http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-model/src/main…
>> .
>>
>> There's nothing to customize so the power of wiki macros wouldn't be
>> used. You can create a wiki macro that wraps the office preview macro
>> and add decorations specific to your needs.
>>
>> One the other hand, the advantages of a Java macro are not significant
>> either because the macro is just a simple wrapper for the office
preview
script service.
WDYT?
+1 for java macro. One advantage is that it will be usable nested inside
scripting macros as well (otherwise the velocity macro inside will
prevent it).