Hi,
On Wed, Sep 22, 2010 at 16:01, Marius Dumitru Florea <
[email protected]> wrote:
> On 09/22/2010 04:31 PM, Marius Dumitru Florea wrote:
> > 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.
> >>
> >
> >> 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
> Office preview component relies entirely on the office importer
> > 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/java/org/xwiki/model/internal/scripting/ModelScriptService.java
> >>> .
> >>>
> >>> 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).
> >>
> > _______________________________________________
> > devs mailing list
> > [email protected]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
