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?
>
> 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
