[xwiki-devs] [Discussion] Office Preview Macro
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. 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? Thanks, Marius
On Wed, Sep 22, 2010 at 12:31, Marius Dumitru Florea <[email protected]> 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.
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 since wiki macro does not bring anything here and java macro does not require to import a xar.
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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?
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). -- Sergiu Dumitriu http://purl.org/net/sergiu/
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. 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).
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/... .
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
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/...
.
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
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? 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/...
.
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
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 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. 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.
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/...
.
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).
-- Sergiu Dumitriu http://purl.org/net/sergiu/
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/... > . > > 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).
On 09/24/2010 04:45 PM, Marius Dumitru Florea wrote:
On 09/24/2010 03:36 PM, Sergiu Dumitriu wrote:
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.
Tiny preview in watchlist mails: New attachment: my slides.odp [screenshot] [screenshot] [screenshot] Tiny preview in the attachments tab: png => small preview of the image, ppt => screenshot of the first slide, doc,pdf => screenshot of the upper part of the first page, txt => screenshot of the upper-left corner of the text file. Konqueror does something like this when browsing the filesystem, and I really like it. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi all, On 09/22/2010 02: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?
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).
If I remember correctly this was fixed, wiki macros should be a special case and allow scripting macro inside scripting macro, otherwise wikimacros will be unusable on an "if" branch. Otherwise, I think I would prefer wikimacro, for this case, since it's more like a "shortcut" (instead of writing {{velocity}}{{html}}...., one just writes {{officepreview ...) I don't like that much the idea of having this kind of shortcuts in the java macros, but I don't have a strong opinion. Thanks, Anca
On Fri, Sep 24, 2010 at 15:37, Anca Luca <[email protected]> wrote:
Hi all,
On 09/22/2010 02: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?
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).
If I remember correctly this was fixed, wiki macros should be a special case and allow scripting macro inside scripting macro, otherwise wikimacros will be unusable on an "if" branch.
Yes it's fixed. See http://jira.xwiki.org/jira/browse/XWIKI-5435.
Otherwise, I think I would prefer wikimacro, for this case, since it's more like a "shortcut" (instead of writing {{velocity}}{{html}}...., one just writes {{officepreview ...) I don't like that much the idea of having this kind of shortcuts in the java macros, but I don't have a strong opinion.
Thanks, Anca
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (5)
-
Anca Luca -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne