On 09/24/2010 03:36 PM, Sergiu Dumitriu wrote:
> On 09/24/2010 11:49 AM, Marius Dumitru Florea wrote:
>> On 09/22/2010 06:25 PM, Guillaume Lerouge wrote:
>>> 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.
>>
>> This looks great, but I can't achieve it with the current tools. When
>> converting a presentation (ppt/odp) to HTML jodconveter generates for
>> each slide an image (screenshot) and an HTML fragment with only the text
>> extracted from that slide.
>>
>> Currently office-importer module displays the imported presentation
>> using an in-line frame. You see the current slide (either image or text)
>> and you have links pointing to the first, previous, next and last slide.
>>
>> I don't like the current behavior and the usage of the html macro to
>> generates the in-line frame generates complications on the
>> implementation side. I'd like to change it to display all the
>> images/text on the same wiki page without using an in-line frame: simply
>> insert the images/text in the wiki syntax. I see two options:
>>
>> (1) Display either only the images or only the text
>>
>> (2) Display both the images and the text (e.g. slide text followed by
>> slide image, or side by side on two columns)
>>
>> WDYT?
>
> Maybe it's just me, but the name of the module, office-preview, gives me
> the impression that this is not trying to be Google Docs, giving an
> exact view of the document/presentation/sheet, but a *preview*: take a
> peek at how this attachment looks, download it if you want to see it for
> real.
>
> So, I see three distinct functionalities related to the office component:
>
> 1. Importing a document into a wiki document, through the current office
> importer. This allows to import either the text, or the text plus the
> full original styling.
>
> 2. Previewing an attached document standalone, like what GMail does for
> attachments: full HTML view of the document, in a fresh tab, without any
> XWiki chrome. We don't have this yet.
>
> 3. Previewing an attachment inside a wiki document. I see this not as
> displaying the full content of the document inline, but as a sneak-peek
> giving an overview of the document. I see this as small thumbnails,
> which link to either the attachment download, or to the standalone
> preview (2). This is what I think the office-preview module should do.
What's the real use case for this small thumbnails? Why would you
display them inside the content of a wiki page? I'd rather display a
thumbnail when hovering a link to an office attachment, but I wouldn't
put the thumbnail inside the content (i.e. using a macro in wiki syntax)
unless I'm creating a gallery, which is a very specific use case.
>
> What I think is closer to the current implementation is:
>
> 4. Including the content of the attachment inside the rendered HTML,
> This can be done either in a seamless manner, where there's no marker
> that something else is included (this is suited for documents and some
> spreadsheets), or like an iframe (suited for presentations and some
> spreadsheets). But in this case, I don't think that the preview name is
> right, maybe office-include is more suited.
Better, office-viewer. The code written by Asiri serves exactly this
purpose: view office attachments without downloading them (either stand
alone or inside a wiki page).
>
> Back to your question, I think that images are better, and the text can
> be placed as the alternative text for images. This has the advantage
> that copy/pasting into a text editor will paste the text.
office-importer extracts HTML from slides (text structured with lists,
headings, etc.). It doesn't seem right to place this HTML code in the
attribute for image alternative text.
Thanks,
Marius
>
>>>
>>> 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
