Document viewer based on pdf.js
Peter Löfgren
project pfd.js. I've posted about it here
http://loftux.com/2012/01/08/replace-alfresco-standard-flash-viewer-with-pdf-js/
The concept is simply: Make a pdf thumbnail and display in iframe,
with pdf.js if possible or fallback to pdf reader plugin if available.
If it is ok I can add it to Share Extras. It probably need some more
testing, for example there is some validation code for html5 support
that may include or exclude browser version that should not. I think
you can help with that, or just some general comments on the code. But
I think i may be useful, at least as a way to show how an alternative
viewer can be implemented.
Question:
I've created a new thumbnail format, I named it 'pdf''.. The way to do
that was found after som egoogling in Share Extras (it is a good
resource, isn't it!) and in Florians javascript console project.
Question here is that the bean needs transformationOptions specified,
but there are no options for pdf transformations. So to get it working
I threw in the swf options. It works, probably just ignored. For this
project, I want to avoid creating java code, it is easier for others
to just check out and build the project then. Is there a better "bean"
to use in this case?
<bean
class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="targetObject" ref="thumbnailRegistry" />
<property name="targetMethod" value="addThumbnailDefinition" />
<property name="arguments">
<list>
<bean
class="org.alfresco.repo.thumbnail.ThumbnailDefinition">
<property name="name" value="pdf" />
<property name="mimetype" value="application/pdf" />
<property name="transformationOptions">
<bean
class="org.alfresco.repo.content.transform.swf.SWFTransformationOptions">
<property name="flashVersion" value="9" />
</bean>
</property>
</bean>
</list>
</property>
</bean>
Cheers,
Peter Löfgren
Peter Löfgren
> I've created an alternative document viewer based on the Mozilla
....
>
> Question:
> I've created a new thumbnail format, I named it 'pdf''.. The way to do
> that was found after som egoogling in Share Extras (it is a good
> resource, isn't it!) and in Florians javascript console project.
....
Correction of myself: It is Florians GalleryPlus Dashlet that has the
thumbnail extension bean.
//Peter Löfgren
Florian Maul
--
You received this message because you are subscribed to the Google Groups "Share Extras Development" group.
To post to this group, send email to share-ext...@googlegroups.com.
To unsubscribe from this group, send email to share-extras-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/share-extras-devel?hl=en.
Peter Löfgren
> Hi Peter,
>
> How about using org.alfresco.service.cmr.repository.TransformationOptions?
>
> It is the parent class SWFTransformationOptions of and appears not to be
> abstract. I think you could instantiate it and not set any properties.
>
> Regards,
> Florian
>
Thanks Florian,
I tried (both with and without a bean name for TransformationOptions).
<bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="targetObject" ref="thumbnailRegistry" />
<property name="targetMethod" value="addThumbnailDefinition" />
<property name="arguments">
<list>
<bean class="org.alfresco.repo.thumbnail.ThumbnailDefinition">
<property name="name" value="pdf" />
<property name="mimetype" value="application/pdf" />
<property name="transformationOptions">
<bean name="PdfViewerNullOptions"
class="org.alfresco.service.cmr.repository.TransformationOptions" />
</property>
</bean>
</list>
</property>
</bean>
But I get (same error with and without bean name)
Caused by: org.alfresco.scripts.ScriptException: 00090012 Failed to
execute script 'classpath*:alfresco/templates/webscripts/org/alfresco/repository/thumbnail/thumbnail.get.js':
No bean named '' is defined
at org.alfresco.repo.jscript.RhinoScriptProcessor.execute(RhinoScriptProcessor.java:195)
at org.alfresco.repo.processor.ScriptServiceImpl.execute(ScriptServiceImpl.java:212)
at org.alfresco.repo.processor.ScriptServiceImpl.executeScript(ScriptServiceImpl.java:174)
at org.alfresco.repo.web.scripts.RepositoryScriptProcessor.executeScript(RepositoryScriptProcessor.java:102)
at org.springframework.extensions.webscripts.AbstractWebScript.executeScript(AbstractWebScript.java:1193)
at org.alfresco.repo.web.scripts.content.StreamContent.execute(StreamContent.java:155)
... 25 more
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException:
No bean named '' is defined
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:527)
Going back to having adding the swfoptions and it works again.
//Peter Löfgren
Will Abson
I was considering adding my example to the Media Previews project (already has thumbnail defs for audio/video content), but yours sounds a lot more advanced. Would you be willing to add it into that project on trunk and we can work on it together? The existing previews need some refactoring for 4.0 but this is a good excuse to get that done.
If we can get this to work solidly across a range of modern browsers I think improved previews could be a real killer feature for Extras and just in time for the upcoming addons directory.
Cheers,
Will
Sent from my iPhone
Peter Löfgren
> Hi Peter, this sounds like a really useful extension! I did put together a similar example myself, which embeds the content itself in an iframe if it is a PDF file, the idea was to make use of Chrome's PDF rendering, which works very well in my experience and is more user-friendly than the Flash previewer.
>
That is what I do as a fall-back if the pdf.js viewer wont work.
Problem here is detection code, both for what level of html5 support
there is, and if a pdf reader plugin is present. Chrome, Safari,
Firefox you can iterate plugins, and se if they are present, built in
or external. IE of course doesn't support this. You have to try to
instantiate the object, new ActiveXObject('AcroPDF.PDF'), and test if
it works. Problem here is to find out all available PDF reader active
x objects. Users will have to report over time.
> I was considering adding my example to the Media Previews project (already has thumbnail defs for audio/video content), but yours sounds a lot more advanced. Would you be willing to add it into that project on trunk and we can work on it together? The existing previews need some refactoring for 4.0 but this is a good excuse to get that done.
Agree with the idea to merge them into one. But since the way of
instantiating viewers has changed for 4.0 I think it may be easier if
I add a new Root project 'Viewer Extension', then we merge from Media
Previews. That project can still exist as add-on for 3.4.
About the name, I think using Viewer rather than Previewer is a better
fit. At one time it may have been just previews that implies that you
do not see the full document, but now you actually can do that.
What I see needs to be done
* Initial checkin of my code
* Merging viewers from Media Previews. Verify if needed, there is some
support in 4.0 for viewing media.
* Merging the Media Preview dashlet, extending to be generic. Why not
just use the "Previewer" and let that functionality select appropriate
render. Different users may see it rendered with different viewers,
but the failover mechanism in the Previewer will test for the best
fit.
* Adding some more "Viewers". I have for one client added a text
preview. Yes, it was needed since there was no way to get the flash
viewer to handle our swedish characters åäö correctly. But the browser
does, so just display them inline. Same goes for html, why display it
in flash, if it is displayed inline (or in iframe, that way one can
actually allow for head, body and img tags to work its magick if
present).
* Figure out the best way to make it user configurable what available
viewers the user want to use. Since we can package multiple in one
package, alfresco admins may not want to make all available.
The configuration files
site-webscripts/org/alfresco/components/preview/web-preview.get.config.xml
determines what viewers are used. A cool way would have been to add
several Surf extension and just turn on/off, but Surf extension
doesn't support the config file for a webscript. So we supply a
default config with all viewers enable and/or instruct users to
download and edit a separate web-preview.get.config.xml
> If we can get this to work solidly across a range of modern browsers I think improved previews could be a real killer feature for Extras and just in time for the upcoming addons directory.
>
> Cheers,
> Will
>
> Sent from my iPhone
>
Cheers, Peter
Will Abson
Hi Peter, glad that makes sense and it sounds like we are thinking along common lines for the PDF viewer.
Since I created the new branch for pre-4.0 stuff we can go ahead and break backwards compatibility on trunk now, so don't worry about that.
I'm open to discussing a change of name if required (although 'document previews' is the term used for the Flash viewer in core Share, so it does mirror that) but I think it's important we keep this related stuff together in the same project.
If you are OK to check your stuff into the Media Previews project for now then I will check in my changes there too (I have done some initial refactoring on my laptop, but since I'm travelling I don't have reliable internet access on it this week).
I think the plain text and HTML previews are a great idea, as you say HTML should be in an iframe for security reasons if nothing else. I've also got another example previewer which uses the WebODF JS lib for rendering ODF format docs within the Com, which I would like to add in.
I am sure there are other formats we could add support for, e.g. code highlighting for scripts, other text markup formats e.g. Textile and more. But I think we have a good list for now.
Cheers,
Will
Peter Löfgren
> Hi Peter, glad that makes sense and it sounds like we are thinking along
> common lines for the PDF viewer.
>
> Since I created the new branch for pre-4.0 stuff we can go ahead and break
> backwards compatibility on trunk now, so don't worry about that.
>
> I'm open to discussing a change of name if required (although 'document
> previews' is the term used for the Flash viewer in core Share, so it does
> mirror that) but I think it's important we keep this related stuff together
> in the same project.
>
> If you are OK to check your stuff into the Media Previews project for now
> then I will check in my changes there too (I have done some initial
> refactoring on my laptop, but since I'm travelling I don't have reliable
> internet access on it this week).
>
> I think the plain text and HTML previews are a great idea, as you say HTML
> should be in an iframe for security reasons if nothing else. I've also got
> another example previewer which uses the WebODF JS lib for rendering ODF
> format docs within the Com, which I would like to add in.
>
> I am sure there are other formats we could add support for, e.g. code
> highlighting for scripts, other text markup formats e.g. Textile and more.
> But I think we have a good list for now.
>
> Cheers,
> Will
Oops, just checked it in to trunk/Viewer Extension. Sorry about being
a bit quick, but I had it all ready and been getting a lot of pings
for the source.
It would have taken a lot of work to merge in to Media Previews to get
it all working due to differences in viewer loading model. Instead
bring in one viewer/applicable source at a time from Media Previews.
Once all is merged over, then the Media Previews from trunk can be
removed.
Maybe move the project to /trunk/Sandbox, do all the merging there,
and then move it to /trunk (with a name change if needed) when it is
ready?
Also in the checkin is an IframeViewer, that loads the file in an
iframe, and that can be used for text and html. I had it done already,
just included that.
Cheers,
Peter
Florian Maul
Cheers,
Peter
Will Abson
that would be good. Just until we merge the two together (probably
next week) and then I'll do a full release of the full set.
Cheers,
Will.
Will Abson
Flash at the time because it has wider coverage than the Adobe reader,
but pdf.js and Chrome change the game somewhat.
I'll ask around next week when I'm back from India next week, since I
agree Flash is not the best choice now in the face of such
alternatives.
Cheers,
Will.
Peter Löfgren
Made some smaller updates to, one is a fix for scroll issue that
scrolled to viewer iframe to top when navigating pages, now it
reposition itself again.
Cheers,
Peter
2012/1/12 Will Abson <will....@gmail.com>:
Peter Löfgren
extensions. In the project there is a default config that adds the new
viewers for the extension in
web-extensions/site-webscripts/org/alfresco/components/preview/web-preview.get.config.xml
This works well, it loads the custom config. But if it is included in
the distribution jar there seem to be no easy way to override this if
you want to have your own config. I've tried to put a custom
web-preview.get.config.xml in different classpath locations, but for
what I can tell, the jar one always wins. Is that the case?
If confirmed that jar has the last say, is it better from share-extras
distribution/packaging point of view not to include the config file in
the jar, and have the users download and add the config separately in
tomcat classpath? Or tell them that if they want custom, they need to
edit and build the project themselves?
Since the project is eventually going to have lots of options for
custom viewers, it is not unlikely users may only want some of them.
Cheers,
Peter Löfgren
Will Abson
On 1 February 2012 11:46, Peter Löfgren <pe...@loftux.se> wrote:
> Follow up on the pdf.js viewer/viewer extension about load order for
> extensions. In the project there is a default config that adds the new
> viewers for the extension in
> web-extensions/site-webscripts/org/alfresco/components/preview/web-preview.get.config.xml
>
> This works well, it loads the custom config. But if it is included in
> the distribution jar there seem to be no easy way to override this if
> you want to have your own config. I've tried to put a custom
> web-preview.get.config.xml in different classpath locations, but for
> what I can tell, the jar one always wins. Is that the case?
That's exactly the problem with using web-extension to add overrides -
you can only do it once, and so if you have multiple add-ons (or one
add-on and some custom config) that try to extend the same component
then it won't work. Something will win - it usually seems to be the
JAR file with Tomcat - but this is completely up to the classloader if
the path is the same for two assets so essentially you cannot say
which one will win.
To get round this to some degree I've just today added a small
customization module to Media Previews trunk, in order to pull in the
client-side dependencies (no .head.ftl override needed!) and to add a
few i18n messages that are specific to the video player. See
config/alfresco/site-data/extensions/org_sharextras_media-previews.xml.
Unfortunately AFAIK, modules don't offer us an alternative for the
config, since .config.xml files are not extendible via a
customization. I'm sure there are hacks possible using an extension
with some additional controller logic, but your key point is that sys
admins should be able to set which viewers are used, and inserting
things into the config at runtime would obviously break that ;-)
> If confirmed that jar has the last say, is it better from share-extras
> distribution/packaging point of view not to include the config file in
> the jar, and have the users download and add the config separately in
> tomcat classpath? Or tell them that if they want custom, they need to
> edit and build the project themselves?
Given the limitations I think it's reasonable (though not ideal) to
tell people to take some sample config, drop it into shared/classes
and modify it to suit their needs. We could tell them to copy the
stock web-preview.get.config.xml into there (like I've done with the
3.x document actions) or supply a ZIP file with the correct
web-extension directory structure that they can just unzip into
shared/classes.
Either way I think the sample config should be outside the JAR, either
in the docs or as a separate download, referenced from the docs.
Of course ideally, the base config would be in the global doclib
config and not in the web script config. That would make it possible
for sys admins to put overrides in share-config-custom.xml and
eliminate the whole mess of having to create all those web script
directories under shared/classes. I'll raise a JIRA on that, but we
are where we are for the current 4.0.
> Since the project is eventually going to have lots of options for
> custom viewers, it is not unlikely users may only want some of them.
Yeah, I've already started playing around with passing different
options to the viewers to change their behaviour, so I'll need to
document changing the XML config for this purpose, as well as for
adding them into the mix in the first place.
Cheers,
Will.
Peter Löfgren
Here is a little weekend problem for you:
I thought it would be easy to convert the configuration that is in
web-preview.get.config.xml to config.scoped in web-preview.get.js.
That way we could overcome the issue of only being able to override
once described earlier. I wanted to keep the current config model
intact, just put it in <alfresco-config><config
evaluator="string-compare" condition="Viewers">. It all works, except
that you cannot read attribute keys. The configuration has "unknown"
attributes, for any viewer you can add any custom attribute needed (I
used that to add for example a way to skip browser compatible tests).
Here is part of the code.
*****
conditionNodes = xmlConfig.getChildren("condition");
for (var i = 0; i < conditionNodes.size(); i++)
{
condition =
{
attributes: {},
plugins: []
};
conditionNode = conditionNodes.get(i);
attributes = conditionNode.getAttributes();
for each (attribute in attributes)
{
//This is what not works - attributes[attribute] returns null
condition.attributes[attributes[attribute]] = attribute;
}
****
typeof attributes return Object, the java class returns java.utils.Map
typeof attribute is String
So I would expect a key value pair, but only value is available. Am I
doing something wrong here? Is it a bug?
The current web-preview.get.js uses config.script that returns XML,
and that is what the current function parses, config.scoped returns
surf ConfigElement. Two different ways for almost the same thing.
Cheers
Peter Löfgren
Will Abson
I've finally made some substantial progress the last few days with
refactoring the old Media Previews project on trunk, so that it works
with v4.0.
I'm aiming to put together a couple of blog posts on this, but I
thought it was worth sending a quick-ish mail to the list initially,
to outline the main parts as of now, and to see if anyone has any
feedback.
So, these are the current contents:
* A custom web-previewer plugin FLVPlayer.js - this was the
Flash-based player I implemented in v3.2 originally to provide some
support for FLV and MP4 video formats, plus anything else that could
be converted via FFmpeg. It's not as nice as the Strobe player shipped
OOTB in Alfresco 4, but it was a good exercise to convert it over, it
has some nice features the OOTB players do not, and so I thought
someone might find it interesting
* A second custom plugin MP3Player.js - similar to the video player,
but implementing support for MP3 files played back via Flash, or any
other format that FFmpeg can convert into MP3. Again from the v3.x
version.
* Some very basic plugins for the PDF-in-iframe and direct embedding
of ODF documents in the Dom using WebODF (WebODF has a AGPL license,
so needs to be distributed separately). I suspect the PDF plugin is
pretty basic compared to Peter's but since I'd already put it together
I thought we might as well compare them within SVN.
* A 'Document Viewer' dashlet - based on the 'Video Preview' dashlet
I included with the original FLV/MP3 player previewers, but it now
works with ANY content type supported by the document details screen
and will respect the web-previewer component configuration
* A customization module which is used to embed the client-side
dependencies for the custom web-previewer plugins into the
document-details page. IMPORTANT: This means no more overriding of
.head.ftl web scripts should be necessary! So multiple projects can
define different web-previewer plugins and they will all sit
side-by-side when deployed.
So the lessons are that Share customization doesn't necessarily get
less easy with 4.0, but the new module options allow you to customize
without overriding any core Share components, i.e. no more
alfresco/web-extension directory in your projects.
Peter, I'll start to look at your plugins next week and start working
out where to fit them in, and I'll have another look at that
scoped-vs-script config issue. I just had to get my own bits in some
kind of order first :-)
Cheers,
Will.
Peter Löfgren
I checked the two viewers I created, Iframe (to be used with content
that can be displayed inline such as text or html) and pdf viewer, it
should be easy to have the loaded with a customization module. I did
not add one, rather wait for the merge.
>
> So the lessons are that Share customization doesn't necessarily get
> less easy with 4.0, but the new module options allow you to customize
> without overriding any core Share components, i.e. no more
> alfresco/web-extension directory in your projects.
>
> Peter, I'll start to look at your plugins next week and start working
> out where to fit them in, and I'll have another look at that
> scoped-vs-script config issue. I just had to get my own bits in some
> kind of order first :-)
I checked in (commit #977) the changes i did to make the config use
global scope. It is currently disabled/not loaded because it doesn't
work, just added it for review purposes.
I have an idea here that may work better:
Instead of moving it all to global scope config, use the augmenting
features of customization modules. In the web-preview.get.js have it
load as it currently does, then extend this file to manipulate
model.pluginConditionsJSON. Adding an object here shouldn't be to
hard, only thing is that order matters so if something needs to be
inserted at a specific position, then it may be harder. But if added
as first options (we want to override, so usually we want them to be
tested as viable viewers first), then it could work.
- Possibly we can have one extension module per viewer
- Config options per viewer, for this to work we still may need some
global config.
>
> Cheers,
> Will.
>
I also recently added
source/web/components/preview/web-preview-extend.js that can be used
for augmenting Alfresco.ViewerExtension. For my purpose it was to add
setupPreviewSize function so that the previewer area makes best
possible use of available preview area size. Now it can be reused, I
used for both Iframe viewer and the pdf viewer.
Cheers, Peter
Will Abson
Hi Peter, I took an initial look today and the client side code looks good, but I'm not quite clear on what you're overriding inside web-extension. It seems you're overriding the main web-preview.get web script, is that right?
I see a reference to an Alfresco.ViewerExtension class in your mail below, are you replacing the Alfresco.WebPreviewer class with an instance of this instead? What does WebPreview not provide that you need and you can't implement in the plugin implementation?
I also had an email exchange with Dave Draper and Erik, who told me there's a better way to add in client side dependencies using an extra .get.head.ftl template linked to a customization. I'll try that out tomorrow in Media Previews and if it works ok I'd like to make that the definitive method of adding the dependencies.
Generally it seems we're both still finding our feet here, and there's some work to be done to agree on a standard approach for additional previewers. That said, I do want to make sure that we can implement this without overriding any core Share web scripts, that we use customization modules where possible, and that the changes we make are as non-invasive as possible. We also need to make sure that we're not using Alfresco name spaces for any web scripts, client side code or other config, and I've substantially refactored the old Media Previews code to generally achieve this.
If I can make those last changes to the dependency injection are you OK if we do the merge from Viewer Extension into Media Previews? I'd suggest it would be easier that way as I have all the Extras directories and package structures set up there already plus the modules.
On the name, maybe we could meet in the middle with 'Media Viewers'? I think the word extension is redundant in the add-on as by definition all add-ons are extensions, but I take your point that viewer is a better word for communicating what this extension does (although I've stuck to previewer in the JSDoc as that's the term used internally inside Share).
Let me know your thoughts.
Cheers,
Will
Peter Löfgren
> Hi Peter, I took an initial look today and the client side code looks good,
> but I'm not quite clear on what you're overriding inside web-extension. It
> seems you're overriding the main web-preview.get web script, is that right?
Yes, I tried to rewrite the getPluginConditions function in
web-preview.get.js (in my checkin with extension NOTINUSE in order not
to break the extension) to read from a global scope config, this is
why the files viewer-extension-config.xml and
viewer-extension-context.xml was added. It works so far as to read the
config, it is just this line
"condition.attributes[attributes[attribute]] = attribute;" that
doesn't supply the key.
>
> I see a reference to an Alfresco.ViewerExtension class in your mail below,
> are you replacing the Alfresco.WebPreviewer class with an instance of this
> instead? What does WebPreview not provide that you need and you can't
> implement in the plugin implementation?
Not replacing, augmenting. Since In my extension there are two viewers
that could use the same functionality (setupPreviewSize), instead of
repeating the code I added that to Alfresco.ViewerExtension by
extending/augmenting it. I think such an approach can be used for all
the extra viewers that may make use of a common function not in the
base Alfresco.ViewerExtension. In that way we can have one file (mine
was named web-preview-extend.js) that is always loaded regardless of
what viewers you enable.
But I see the comment header in that file is confusing, I'll rewrite
that, and as mentioned by you below, not use the Alfresco namespace if
possible.
>
> I also had an email exchange with Dave Draper and Erik, who told me there's
> a better way to add in client side dependencies using an extra .get.head.ftl
> template linked to a customization. I'll try that out tomorrow in Media
> Previews and if it works ok I'd like to make that the definitive method of
> adding the dependencies.
I'll have a look at what you add, and when we merge follow the same principle.
>
> Generally it seems we're both still finding our feet here, and there's some
> work to be done to agree on a standard approach for additional previewers.
> That said, I do want to make sure that we can implement this without
> overriding any core Share web scripts, that we use customization modules
> where possible, and that the changes we make are as non-invasive as
> possible. We also need to make sure that we're not using Alfresco name
> spaces for any web scripts, client side code or other config, and I've
> substantially refactored the old Media Previews code to generally achieve
> this.
It's a good exercise, maybe this can come out not only as a useful
extension, but also as an example of how to extend.
>
> If I can make those last changes to the dependency injection are you OK if
> we do the merge from Viewer Extension into Media Previews? I'd suggest it
> would be easier that way as I have all the Extras directories and package
> structures set up there already plus the modules.
Yes, that is the way we should do it now.
Note that pdf.js cannot use yuicompressor due to bug
https://github.com/mozilla/pdf.js/issues/710, they are using reserved
future keywords in the js, and they wont change it. So for these
specific scripts we need to use a different compressor (like the one I
use). I'll look at some changes to the build so that all other js
files use yuicompressor, and
>
> On the name, maybe we could meet in the middle with 'Media Viewers'? I think
> the word extension is redundant in the add-on as by definition all add-ons
> are extensions, but I take your point that viewer is a better word for
> communicating what this extension does (although I've stuck to previewer in
> the JSDoc as that's the term used internally inside Share).
Agree.
>
> Let me know your thoughts.
>
> Cheers,
> Will
Cheers,
Peter
Will Abson
On Feb 14, 2012 8:30 PM, "Peter Löfgren" <pe...@loftux.se> wrote:
>
> 2012/2/14 Will Abson <will....@gmail.com>:
> > Hi Peter, I took an initial look today and the client side code looks good,
> > but I'm not quite clear on what you're overriding inside web-extension. It
> > seems you're overriding the main web-preview.get web script, is that right?
>
> Yes, I tried to rewrite the getPluginConditions function in
> web-preview.get.js (in my checkin with extension NOTINUSE in order not
> to break the extension) to read from a global scope config, this is
> why the files viewer-extension-config.xml and
> viewer-extension-context.xml was added. It works so far as to read the
> config, it is just this line
> "condition.attributes[attributes[attribute]] = attribute;" that
> doesn't supply the key.
That makes sense now. I see you have overridden the .head.ftl template but that can easily be extended now according to Dave and the testing I did today (now checked in) validated that. As for the config, that's a difficult one and I'd so suggest we come back to that later.
I was also getting confused with your custom page definition and template and thinking that was somehow replacing a normal page component but looking at it again I see it's a custom page connedctedd with the PDF plug in, somehow?
> > I see a reference to an Alfresco.ViewerExtension class in your mail below,
> > are you replacing the Alfresco.WebPreviewer class with an instance of this
> > instead? What does WebPreview not provide that you need and you can't
> > implement in the plugin implementation?
>
> Not replacing, augmenting. Since In my extension there are two viewers
> that could use the same functionality (setupPreviewSize), instead of
> repeating the code I added that to Alfresco.ViewerExtension by
> extending/augmenting it. I think such an approach can be used for all
> the extra viewers that may make use of a common function not in the
> base Alfresco.ViewerExtension. In that way we can have one file (mine
> was named web-preview-extend.js) that is always loaded regardless of
> what viewers you enable.
> But I see the comment header in that file is confusing, I'll rewrite
> that, and as mentioned by you below, not use the Alfresco namespace if
> possible.
Again, makes sense thanks. I think I would prefer that the additional functions are defined on the plugins, rather than on the core Share class, but you could easily define a base class where the functions are defined, and that is then extended by both plugins. Would that work?
On the name spaces, I should probably put together a doc on this but in summary
Client side classes are defined in the Extras global object
Client side resources should all exist under the 'extras' top level directory under source/web
Web script packages should normally begin org.sharextras.components (note one 'e', same as the web domain)
> > I also had an email exchange with Dave Draper and Erik, who told me there's
> > a better way to add in client side dependencies using an extra .get.head.ftl
> > template linked to a customization. I'll try that out tomorrow in Media
> > Previews and if it works ok I'd like to make that the definitive method of
> > adding the dependencies.
>
> I'll have a look at what you add, and when we merge follow the same principle.
Checked in as r991.
> > If I can make those last changes to the dependency injection are you OK if
> > we do the merge from Viewer Extension into Media Previews? I'd suggest it
> > would be easier that way as I have all the Extras directories and package
> > structures set up there already plus the modules.
>
> Yes, that is the way we should do it now.
> Note that pdf.js cannot use yuicompressor due to bug
> https://github.com/mozilla/pdf.js/issues/710, they are using reserved
> future keywords in the js, and they wont change it. So for these
> specific scripts we need to use a different compressor (like the one I
> use). I'll look at some changes to the build so that all other js
> files use yuicompressor, and
I should be able to add an exclusion filter that's used specifically when minimizing files. Ideally the value of the filter would be defined in build.properties so that it can be changed on a per project basis to prevent minimisation of any third party libraries being attempted. Changes to build.xml can only be made if they can be replicated across all projects, but there are workarounds involving a second project specific file if build.properties can't be used. I'll take a look.
Will Abson
I had a thought on the web-preview config - we could define a user
preference (or set of) that allows users to choose which viewer to use
for different content types. The different viewers would need to
register themselves inside some scoped config, and then that would be
used to generate a drop-down list or picker that allows them to choose
from a list of viewers for each major content type. The default order
would be as defined by web-preview.get.config.xml, if the preference
is not set.
There would be a little bit work around creating some UI to allow
users to set the preference value, but I think this is a gap that
needs filling anyway.
I'd propose doing that in a separate project, leaving this one to just
define the extra viewers along with some instructions to tell a Share
admin how they can override the web-preview.get.config.xml file.
Since there seems to be some interest gathering around PDF rendering
in particular within Share [1], I'd like to move forward and start
merging your work over into the existing project. Is there anything
else you'd like to complete before I do this?
Cheers,
Will
[1] https://forums.alfresco.com/en/viewtopic.php?f=48&t=43573
Peter Löfgren
idea. That would per mime type, if more than one let the user set the
preference order (it should still have the fallback mechanism that is
in place today if a previewer fails).
Once the merge is done, we can branch it and start on that extension.
The pdf.js viewer (including the iframe viewer) is ready for merge.
What needs to change is
config/web-extension/site-webscripts/org/alfresco/components/preview,
that needs to go into the surf extension, and config into a sample
config. I have done some css styling to make it look more Alfresco,
using Alfresco icons. Also just updated so it is the latest pdf.js
code.
Also check out the build script that have special minimize for pdf.js.
Your current surf extension module (Media Previews Add-on) loads all
extension dependencies. Maybe have one per viewer, so that only the
ones that admins wants gets loaded. I'm thinking we should not load
more than needed, Share already has quite a few dependecies. Or have
the build script concat and then minify the one js file for production
mode to save some requests. Not sure if it is a real issue, but at
least should be considered. Especially if the number of different
viewers grow even more.
What about documentation? Should we have one master viewers page, and
then add subpages for the different included viewers.
Go ahead and make the merge.
Cheers,
Peter
2012/3/19 Will Abson <will....@gmail.com>:
Peter Löfgren
Media Previews.
There were some changes made to the externally sourced pdf.js that
finally made yuicompress minify the file. Unfortunately there is a bug
http://yuilibrary.com/projects/yuicompressor/ticket/2528049 (and
almost 2 years old!) that breaks the pdf.js code when minified. There
may be other bugs in yuicompress in relation to pdf.js as well, trying
to run with yuicompress minified files give all sorts of errors.
Latest version of yuicompress does not help.
So I updated the build file to use jsmin from http://code.google.com/p/jsmin-ant-task/
for all pdf.js related files and in my test it works well. Does not
compress as much as yuicompress, but the difference is small.
Trying to keep up with the external pdf.js project i have updated
those source files. So for the merge, copy everything from
source/web/extras/components/preview
config/alfresco/site-webscripts/org/shareextras/components/preview
Also note that I previously updated the project to not load the config
by default, moved to sample-config folder. And the Viewers are now
loaded as surf extensions.
Cheers,
Peter
>
>
>
>
>
>
> > Hi Peter,
>
> > I had a thought on the web-preview config - we could define a user
> > preference (or set of) that allows users to choose which viewer to use
> > for different content types. The different viewers would need to
> > register themselves inside some scoped config, and then that would be
> > used to generate a drop-down list or picker that allows them to choose
> > from a list of viewers for each major content type. The default order
> > would be as defined by web-preview.get.config.xml, if the preference
> > is not set.
>
> > There would be a little bit work around creating some UI to allow
> > users to set the preference value, but I think this is a gap that
> > needs filling anyway.
>
> > I'd propose doing that in a separate project, leaving this one to just
> > define the extra viewers along with some instructions to tell a Share
> > admin how they can override the web-preview.get.config.xml file.
>
> > Since there seems to be some interest gathering around PDF rendering
> > in particular within Share [1], I'd like to move forward and start
> > merging your work over into the existing project. Is there anything
> > else you'd like to complete before I do this?
>
> > Cheers,
> > Will
>
> > [1]https://forums.alfresco.com/en/viewtopic.php?f=48&t=43573
>
>
> >> On Feb 14, 2012 8:30 PM, "Peter Löfgren" <pe...@loftux.se> wrote:
>
ErikWinlöf
I'm not 100% sure what the actual objective for such a customization/
extension/module is, but here's a sum up of some alternatives based on
your suggestions and some input from me:
A) The pdf.js previewer is an extension module with:
* WEB-INF/classes/site-data/extensions/extras-pdfpreview-extension.xml
- without an evaluator so it always is activated
* WEB-INF/classes/site-webscripts/extras/customization/components/
previewer/web-preview.get.head.ftl - imports resources
* WEB-INF/classes/site-webscripts/extras/customization/components/
previewer/web-preview.get.properties - for the buttons
* web/extras/components/preview/pdfpreviewer.js
* web/extras/components/preview/pdfpreviewer.css
In other words the previewer is ready to be "activated" when
configured in by the "server administrator" that then would override
the .get.config.xml where he by himself can decide which previewer
plugins to use AND in which order the plugins shall be used.
B) An extension module just like A) but also with:
* a <config evaluator="string-compare" condition="Viewers"> section
that adds a <condition> element for the PdfPreviewer previewer (inside
the extras-pdfpreview-extension.xml).
As you already know supported on HEAD since a month but not in a
release yet.
* We support a user preference (as was suggested)
This of course means we would have to use something like Peter's code
for reading "share-config.xml" configs, and also that the PdfPreviewer
would be available without configuration by anybody.
However it would only be used if none of the other previewers kicked
in since it would be placed at the end of the list, which is kind of
lame.
However maybe dropdown of possible plugins and a user preference would
solve that.
C) An extension module like in B) but with a "mix of configs":
- We move the config in web-preview.get.config.xml to be placed inside
a "share-config.xml" as default.
- We read the "share-config.xml" configs ONLY if none is provided
inside the web-preview.get.config.xml file.
This means that extension modules can be configured to "simply work"
as in B) but that a "server administrator" could, if he wants, make a
fine grained config that would govern which viewers to use AND which
the prefered order for them to be used would be.
As a side note I wonder if it would make sense to split up the
different "native" plugins as much as possible. In other words,
instead of adding support for all of them inside the pdf.js so we
could have one plugin <condition> for just pdf.js, one for iframe and
one for each IE-plugin (in this case by creating a "generic plugin"
that checks the plugin using a "pluginname" attribute" so it can be
reused for "AcroPDF.PDF", "PDF.PdfCtrl" etc and also for other
"native" plugins).
That would make it possible for a "server administrator" to cherry
pick and decide the exact order, rather than just saying if they want
to use pdf.js.
Just a thought, not sure if the config would be too complex or not?
Cheers,
:: Erik
On 12 Apr, 09:02, Peter Löfgren <pe...@loftux.se> wrote:
> Some updates on the Sandbox/Viewer Extension, that may need merge to
> Media Previews.
>
> There were some changes made to the externally sourced pdf.js that
> finally made yuicompress minify the file. Unfortunately there is a bughttp://yuilibrary.com/projects/yuicompressor/ticket/2528049(and
> almost 2 years old!) that breaks the pdf.js code when minified. There
> may be other bugs in yuicompress in relation to pdf.js as well, trying
> to run with yuicompress minified files give all sorts of errors.
> Latest version of yuicompress does not help.
Will Abson
> Some updates on the Sandbox/Viewer Extension, that may need merge to
> Media Previews.
>
> There were some changes made to the externally sourced pdf.js that
> finally made yuicompress minify the file. Unfortunately there is a bug
> http://yuilibrary.com/projects/yuicompressor/ticket/2528049 (and
> almost 2 years old!) that breaks the pdf.js code when minified. There
> may be other bugs in yuicompress in relation to pdf.js as well, trying
> to run with yuicompress minified files give all sorts of errors.
> Latest version of yuicompress does not help.
> So I updated the build file to use jsmin from http://code.google.com/p/jsmin-ant-task/
> for all pdf.js related files and in my test it works well. Does not
> compress as much as yuicompress, but the difference is small.
I've noticed that many JavaScript utilities provide their own build
scripts or already-minimised and combined JS code in builds. If so, we
should use those files, but if they do not(?) then I agree it is
reasonable to use jsmin.
One point on making changes to build.xml though, is that I'm keen not
to fork this file at all. It's better if possible to create a
project.xml and have that include build.xml. You get access to the
existing targets and can selectively override them as you need to in
the project-specific file. You can also change the Ant project name
there, as per my comments on
http://code.google.com/p/share-extras/issues/detail?id=16.
> Trying to keep up with the external pdf.js project i have updated
> those source files. So for the merge, copy everything from
> source/web/extras/components/preview
> config/alfresco/site-webscripts/org/shareextras/components/preview
Makes sense. I was chatting with Mike F earlier and he too mentioned
how fast the project is moving. I suppose frequent point updates will
be needed to keep up with pdf.js and he also suggested that we should
mark that viewer as experimental.
Cheers,
Will
Will Abson
On 12 April 2012 10:42, ErikWinlöf <erik....@gmail.com> wrote:
> Hi,
>
> I'm not 100% sure what the actual objective for such a customization/
> extension/module is, but here's a sum up of some alternatives based on
> your suggestions and some input from me:
>
>
> A) The pdf.js previewer is an extension module with:
> * WEB-INF/classes/site-data/extensions/extras-pdfpreview-extension.xml
> - without an evaluator so it always is activated
> * WEB-INF/classes/site-webscripts/extras/customization/components/
> previewer/web-preview.get.head.ftl - imports resources
> * WEB-INF/classes/site-webscripts/extras/customization/components/
> previewer/web-preview.get.properties - for the buttons
> * web/extras/components/preview/pdfpreviewer.js
> * web/extras/components/preview/pdfpreviewer.css
>
> In other words the previewer is ready to be "activated" when
> configured in by the "server administrator" that then would override
> the .get.config.xml where he by himself can decide which previewer
> plugins to use AND in which order the plugins shall be used.
I think we concluded that this is what we'll have for the upcoming release.
> B) An extension module just like A) but also with:
> * a <config evaluator="string-compare" condition="Viewers"> section
> that adds a <condition> element for the PdfPreviewer previewer (inside
> the extras-pdfpreview-extension.xml).
> As you already know supported on HEAD since a month but not in a
> release yet.
My feeling on this is that it should be implemented upstream. I like
Peter's work because it allows us to experiment with the different
options and understand how they would work in practice, but this a
framework thing really that should be handled better by Share. of
course, it's up to us to raise a JIRA and I'm happy to do that using
Peter's code as a basis.
> * We support a user preference (as was suggested)
I still think this is the best solution, it's analogous to a user in
the OS being able to select which app they open a particular type of
file with. But it would not be trivial to implement and for that
reason should be de-coupled from this release and probably this
add-on.
> This of course means we would have to use something like Peter's code
> for reading "share-config.xml" configs, and also that the PdfPreviewer
> would be available without configuration by anybody.
> However it would only be used if none of the other previewers kicked
> in since it would be placed at the end of the list, which is kind of
> lame.
> However maybe dropdown of possible plugins and a user preference would
> solve that.
>
>
> C) An extension module like in B) but with a "mix of configs":
> - We move the config in web-preview.get.config.xml to be placed inside
> a "share-config.xml" as default.
> - We read the "share-config.xml" configs ONLY if none is provided
> inside the web-preview.get.config.xml file.
>
> This means that extension modules can be configured to "simply work"
> as in B) but that a "server administrator" could, if he wants, make a
> fine grained config that would govern which viewers to use AND which
> the prefered order for them to be used would be.
Sounds like the best option to me. If I interpret what you're saying
correctly then it means that we would add the viewer to the end of the
<plugin-conditions> list in the add-on's share-config-custom.xml, but
an admin could override everything by using replace="true" on the
Viewers config block in the web-extension share-config-custom.xml.
The problem with that is that if you look at the
webframework.configsource bean (in slingshot-application-context.xml)
then you'll see that JAR-provided config files are read in *after*
web-extension/share-config-custom.xml. This seems to contradict the
idea that the admin should get the final say, rather than the
developer, so could it be considered a bug?
> As a side note I wonder if it would make sense to split up the
> different "native" plugins as much as possible. In other words,
> instead of adding support for all of them inside the pdf.js so we
> could have one plugin <condition> for just pdf.js, one for iframe and
> one for each IE-plugin (in this case by creating a "generic plugin"
> that checks the plugin using a "pluginname" attribute" so it can be
> reused for "AcroPDF.PDF", "PDF.PdfCtrl" etc and also for other
> "native" plugins).
> That would make it possible for a "server administrator" to cherry
> pick and decide the exact order, rather than just saying if they want
> to use pdf.js.
Agreed 100%. This is why Share ships with four different media plugins
available, since it allows admins to pick exactly the ones they want.
Some people might consider pdf.js too unstable but are happy to use
the iframe embed of a PDF in Chrome, for example.
Erik Winlöf
> In other words the previewer is ready to be "activated" whenI think we concluded that this is what we'll have for the upcoming release.
> configured in by the "server administrator" that then would override
> the .get.config.xml where he by himself can decide which previewer
> plugins to use AND in which order the plugins shall be used.
> * We support a user preference (as was suggested)I still think this is the best solution, it's analogous to a user in
the OS being able to select which app they open a particular type of
file with. But it would not be trivial to implement and for that
reason should be de-coupled from this release and probably this
add-on.
> C) An extension module like in B) but with a "mix of configs":Sounds like the best option to me. If I interpret what you're saying
> - We move the config in web-preview.get.config.xml to be placed inside
> a "share-config.xml" as default.
> - We read the "share-config.xml" configs ONLY if none is provided
> inside the web-preview.get.config.xml file.
>
> This means that extension modules can be configured to "simply work"
> as in B) but that a "server administrator" could, if he wants, make a
> fine grained config that would govern which viewers to use AND which
> the prefered order for them to be used would be.
correctly then it means that we would add the viewer to the end of the
<plugin-conditions> list in the add-on's share-config-custom.xml, but
an admin could override everything by using replace="true" on the
Viewers config block in the web-extension share-config-custom.xml.
The problem with that is that if you look at the
webframework.configsource bean (in slingshot-application-context.xml)
then you'll see that JAR-provided config files are read in *after*
web-extension/share-config-custom.xml. This seems to contradict the
idea that the admin should get the final say, rather than the
developer, so could it be considered a bug?
> As a side note I wonder if it would make sense to split up theAgreed 100%. This is why Share ships with four different media plugins
> different "native" plugins as much as possible. In other words,
> instead of adding support for all of them inside the pdf.js so we
> could have one plugin <condition> for just pdf.js, one for iframe and
> one for each IE-plugin (in this case by creating a "generic plugin"
> that checks the plugin using a "pluginname" attribute" so it can be
> reused for "AcroPDF.PDF", "PDF.PdfCtrl" etc and also for other
> "native" plugins).
> That would make it possible for a "server administrator" to cherry
> pick and decide the exact order, rather than just saying if they want
> to use pdf.js.
available, since it allows admins to pick exactly the ones they want.
Some people might consider pdf.js too unstable but are happy to use
the iframe embed of a PDF in Chrome, for example.
Peter Löfgren
> On 12 April 2012 08:02, Peter Löfgren <pe...@loftux.se> wrote:
>> Some updates on the Sandbox/Viewer Extension, that may need merge to
>> Media Previews.
>>
>> There were some changes made to the externally sourced pdf.js that
>> finally made yuicompress minify the file. Unfortunately there is a bug
>> http://yuilibrary.com/projects/yuicompressor/ticket/2528049 (and
>> almost 2 years old!) that breaks the pdf.js code when minified. There
>> may be other bugs in yuicompress in relation to pdf.js as well, trying
>> to run with yuicompress minified files give all sorts of errors.
>> Latest version of yuicompress does not help.
>> So I updated the build file to use jsmin from http://code.google.com/p/jsmin-ant-task/
>> for all pdf.js related files and in my test it works well. Does not
>> compress as much as yuicompress, but the difference is small.
>
> I've noticed that many JavaScript utilities provide their own build
> scripts or already-minimised and combined JS code in builds. If so, we
> should use those files, but if they do not(?) then I agree it is
> reasonable to use jsmin.
They do not provide that, and there are some small modifications by me
to pdfviewer.js to handle the case that the viewer is within an iframe
to handle scrolling. So we have to compress the files in this
project.
>
> One point on making changes to build.xml though, is that I'm keen not
> to fork this file at all. It's better if possible to create a
> project.xml and have that include build.xml. You get access to the
> existing targets and can selectively override them as you need to in
> the project-specific file. You can also change the Ant project name
> there, as per my comments on
> http://code.google.com/p/share-extras/issues/detail?id=16.
>
I've change and committed to use the same build.xml as in Media
Preview, with a project.xml override.
Two things I noticed from this exercise
- Maybe flip what loads what, make project.xml the default one, and
build.xml the override one. Reason for this is that if you just type
ant, it will load the build.xml and get a successful build, but the
resulting jar will be broken due to the yuicompressor bug. You can of
course have it in the build instructions to use ant -f project.xml.
- Split the copy and compress (like in dist-jar target) to two
different targets. I had to do this in project.xml to be able to
override the compress easily. If you do this split in the default
build.xml instead, the project.xml override needs a lot less
overriding definitions.
>> Trying to keep up with the external pdf.js project i have updated
>> those source files. So for the merge, copy everything from
>> source/web/extras/components/preview
>> config/alfresco/site-webscripts/org/shareextras/components/preview
>
> Makes sense. I was chatting with Mike F earlier and he too mentioned
> how fast the project is moving. I suppose frequent point updates will
> be needed to keep up with pdf.js and he also suggested that we should
> mark that viewer as experimental.
It is surprisingly stable nonetheless. It fails to render properly
with some odd pdf:s still I guess, there are pdf tools out there that
produce very complex pdf files. What works very well is to use the
Alfresco transformation (of ms office and open office) via open office
to pdf, the resulting files renders perfectly with pdf.js, TOC gets
included in the pdf if you have used header styles in your document.
So for files that are pdf:s when added to Alfresco, it may fail. When
transformed to pdf by Alfresco, pdf.js works.
But agree that is can be labeled experimental, the experience can
still be very different between browsers.
>
> Cheers,
> Will
>
Cheers,
Peter
Peter Löfgren
That is probably a change that is better to do in Alfresco core
instead of this project, making it easier to override. And to take
into consideration how a user preference can play well with this. If
an index is added to the config like there is for actions and
templates in the documentlibrary the setting the order becomes easier.
When had the idea of adding pdf viewer support I wasn't aware of the
fall-back mechanism that is already present, so in a way I have
duplicated it. So I agree that the veiwer should be split in two. By
doing this I can remove "forceplugin" code (it is kind of messy
anyway), instead priority/fallback will be set by config and default
functionality-
But there need only to be one PdfPlugin viewer. We cannot have a say
with code what pdf plugin to use, only test if there is one present or
not. Problem child here is IE (of course), there is where you need to
use active x to test if it is available. So I will add a property
(with defaults if not provided) for an array of ActiveX controls to
test for that admins can override, like
<condition mimeType="application/pdf">
<plugin IEactiveX="AcroPDF.PDF,PDF.PdfCtrl">PdfPluginViewer</plugin>
</condition>
Will, do you want to complete the merge first, and I'll do the change
in the Media Preview project, or commit to Sandbox/Viewer Extension?
>
> Cool, this is obvisouly what I tried to illustrate in the config above w the
> "NativePlugin".
>
> Would be great to get some feedback from you Peter, what are your thoughts?
>
> :: Erik
>
Cheers
Peter
Erik Winlöf
instead of this project, making it easier to override. And to takeThat is probably a change that is better to do in Alfresco core
into consideration how a user preference can play well with this. If
an index is added to the config like there is for actions and
templates in the documentlibrary the setting the order becomes easier.
When had the idea of adding pdf viewer support I wasn't aware of the
fall-back mechanism that is already present, so in a way I have
duplicated it. So I agree that the veiwer should be split in two. By
doing this I can remove "forceplugin" code (it is kind of messy
anyway), instead priority/fallback will be set by config and default
functionality-
But there need only to be one PdfPlugin viewer. We cannot have a say
with code what pdf plugin to use, only test if there is one present or
not. Problem child here is IE (of course), there is where you need to
use active x to test if it is available. So I will add a property
(with defaults if not provided) for an array of ActiveX controls to
test for that admins can override, like
<condition mimeType="application/pdf">
<plugin IEactiveX="AcroPDF.PDF,PDF.PdfCtrl">PdfPluginViewer</plugin>
</condition>
Peter Löfgren
I've used iframe to kick in a PdfPlugin, are you (Erik) suggesting to
use <object> or <embed>? Would the advantage be more control via
javascript?
<embed> is only supported in html5, so <object> tag is then preferred
(else lots of tests for compatibility).
But some quick tests shows that for example Chromes build in pdf
viewer doesn't embedd well, se for example http://pdfobject.com/ (some
test pages there). The embedded pdf doesn't scale. So maybe for now
iframe is better. Using iframe, you let the browser take care of
embedding. But I don't think one approach need to rule out another,
certain pdf-plugins may be better of using <object> embedding, but
that would need lots of special case coding.
Your other discussion around for example <plugin
name="AcroPDF.PDF">Embed</plugin> I do not quite follow. That would be
IE only, because only in IE can you test for a specific plugin using
the ActiveX id. Still, I think you can do that with the refactored
PDfPlugin setting the property for IEactiveX I have now added.
If you are looking for a more generic Browser plugin embedder, we need
find a way to reliably test if it is installed, since we need
different methods for IE and other browsers, one by mimetype, other by
ActiveX. Thinking of it when writing this, it may not be that hard to
do (maybe another refactor of PdfPlugin coming).
This is from the commit message of my refactor
-------
Refactored PdfViewer Plugin
- Split to 2 viewers, PdfJs and PdfPlugin
-> You must re-enable viewers in /share/modules/deploy
-> Update your config in web-preview-get.config.xml, see sample_config
-> New setting in PdfPlugin for IE browser PDF Plugin: IEactiveX, set
the ActiveX id to test for installed Pdf Plugins. So if you use IE and
a special PDf Plugin, you can now enbale it by using config.
This split allows to use the already present priority/fallback
mechanism in core preview functionality. By simple re-ordering in the
config, admins can set the preferred load order/priority.
- Moved css and web-preview-extend.js to new customization "Media
Preview Common".
-> This must always be enabled for 3 viewers
This change was made to avoid duplicate loading of resources.
-------
I have one follow up question in regards to surf extensions, I added a
"common" extension to load shared resources, because i noticed for
example web-preview-extend.js was loaded three times (it is needed by
all three). I thought first that surf noticed duplicated resources (in
this case for multiple extended web-preview-get-config.xml) and only
output it once, but that seem not to be the case. Is this approach the
best one?
Cheers, Peter
Erik Winlöf
use <object> or <embed>? Would the advantage be more control viaI've used iframe to kick in a PdfPlugin, are you (Erik) suggesting to
javascript?
<embed> is only supported in html5, so <object> tag is then preferred
(else lots of tests for compatibility).
But some quick tests shows that for example Chromes build in pdf
viewer doesn't embedd well, se for example http://pdfobject.com/ (some
test pages there). The embedded pdf doesn't scale. So maybe for now
iframe is better. Using iframe, you let the browser take care of
embedding. But I don't think one approach need to rule out another,
certain pdf-plugins may be better of using <object> embedding, but
that would need lots of special case coding.
Your other discussion around for example <plugin
name="AcroPDF.PDF">Embed</plugin> I do not quite follow. That would be
IE only, because only in IE can you test for a specific plugin using
the ActiveX id. Still, I think you can do that with the refactored
PDfPlugin setting the property for IEactiveX I have now added.
If you are looking for a more generic Browser plugin embedder, we need
find a way to reliably test if it is installed, since we need
different methods for IE and other browsers, one by mimetype, other by
ActiveX. Thinking of it when writing this, it may not be that hard to
do (maybe another refactor of PdfPlugin coming).
This is from the commit message of my refactor
-------
Refactored PdfViewer Plugin
- Split to 2 viewers, PdfJs and PdfPlugin
-> You must re-enable viewers in /share/modules/deploy
-> Update your config in web-preview-get.config.xml, see sample_config
-> New setting in PdfPlugin for IE browser PDF Plugin: IEactiveX, set
the ActiveX id to test for installed Pdf Plugins. So if you use IE and
a special PDf Plugin, you can now enbale it by using config.
This split allows to use the already present priority/fallback
mechanism in core preview functionality. By simple re-ordering in the
config, admins can set the preferred load order/priority.
- Moved css and web-preview-extend.js to new customization "Media
Preview Common".
-> This must always be enabled for 3 viewers
This change was made to avoid duplicate loading of resources.
-------
I have one follow up question in regards to surf extensions, I added a
"common" extension to load shared resources, because i noticed for
example web-preview-extend.js was loaded three times (it is needed by
all three). I thought first that surf noticed duplicated resources (in
this case for multiple extended web-preview-get-config.xml) and only
output it once, but that seem not to be the case. Is this approach the
best one?
Will Abson
>> I have one follow up question in regards to surf extensions, I added a
>> "common" extension to load shared resources, because i noticed for
>> example web-preview-extend.js was loaded three times (it is needed by
>> all three). I thought first that surf noticed duplicated resources (in
>> this case for multiple extended web-preview-get-config.xml) and only
>> output it once, but that seem not to be the case. Is this approach the
>> best one?
>
>
> Yes new versions of Spring Surf shall handle that, but I vaguely remember a
> bug like that.
> I think we should avoid the "common" extension and file a jira for it and
> assume it will be fixed.
> (Well unless its causing a bug at the moment)
I must agree with Erik here, I'm afraid. I understand the logic of the
common extension avoiding duplicated code, but in reality I've found
that when you have dependencies on another add-on it causes more
problems that it solves, and I think a common extension will suffer
the same problem. Take a look at the comments on the Yammer Dashlet
wiki page if you don't believe me...
Cheers,
Will
Cheers,
Willl
Will Abson
> When had the idea of adding pdf viewer support I wasn't aware of the
> fall-back mechanism that is already present, so in a way I have
> duplicated it. So I agree that the veiwer should be split in two. By
> doing this I can remove "forceplugin" code (it is kind of messy
> anyway), instead priority/fallback will be set by config and default
> functionality-
> But there need only to be one PdfPlugin viewer. We cannot have a say
> with code what pdf plugin to use, only test if there is one present or
> not. Problem child here is IE (of course), there is where you need to
> use active x to test if it is available. So I will add a property
> (with defaults if not provided) for an array of ActiveX controls to
> test for that admins can override, like
> <condition mimeType="application/pdf">
> <plugin IEactiveX="AcroPDF.PDF,PDF.PdfCtrl">PdfPluginViewer</plugin>
> </condition>
>
> Will, do you want to complete the merge first, and I'll do the change
> in the Media Preview project, or commit to Sandbox/Viewer Extension?
Yes, let's freeze this now and I'll try and get the merge finished
this week. Then we can re-start development after that.
Cheers,
Will
Will Abson
The module builds perfectly with the project.xml build script, but I
did see there is a lot of additional/overridden targets in this file.
I'd like to understand why that is, ideally project.xml would contain
just a few extra lines but perhaps changes are needed in build.xml to
make it more modular. But let's park that for now as it's more
important to get the plugins working as well as they can.
The good news is that the PdfPlugin viewer seems to work perfectly on
FF and Chrome. In Chrome it looks nice, and I really like the top bar
and the addition of the View in Browser button. That really helps.
Likewise the iframe viewer works well for plain text. For HTML it
displays the mark-up rather than rendering it in the browser, so I'd
like to investigate that a bit more.
PdfJs is also working, but I refactored it slightly, removing the
custom Surf page and instead using the URL of the pdviewerform.get
webscript directly. I updated the URL path in line 143 of PdfJs.js,
and also applied the encodeURIComponent() function to the URL
parameters used (file and htmlid, the latter being referenced in the
web script) since the web script runtime was throwing errors with the
unescaped content URL being passed as a parameter. It seems to work
fine with those changes.
I'd would still like to make a couple more changes to this latter
plugin, though, having understood it a bit better now (I think). I'd
like to get rid of the iframe, as the example code on jsbin.com[1]
seems to avoid this and just loads the PDF directly. I see the web
script is useful for defining the form markup, so I would keep this
but try loading it via XHR (instead of frame) and inject it into the
plugin <div> on the page. I would also make the buttons more YUI-like,
as this could be a really good example of an advanced
JavaScript-driven viewer, but just needs to fit in a bit better
stylistically, but also to use YUI Events hooked up to plugin class
methods, rather than explicit onclick attributes on the button
elements.
Let me know if you can see any reasons why this won't work, otherwise
I'll start taking a look at this.
Cheers,
Will.
[1] http://jsbin.com/pdfjs-helloworld/edit#html,live
Peter Löfgren
> I completed the merge this morning with r1052 and r1053.
>
> The module builds perfectly with the project.xml build script, but I
> did see there is a lot of additional/overridden targets in this file.
> I'd like to understand why that is, ideally project.xml would contain
> just a few extra lines but perhaps changes are needed in build.xml to
> make it more modular. But let's park that for now as it's more
> important to get the plugins working as well as they can.
Quoting myself from earlier in this discussion:
"I've change and committed to use the same build.xml as in Media
Preview, with a project.xml override.
Two things I noticed from this exercise
- Maybe flip what loads what, make project.xml the default one, and
build.xml the override one. Reason for this is that if you just type
ant, it will load the build.xml and get a successful build, but the
resulting jar will be broken due to the yuicompressor bug. You can of
course have it in the build instructions to use ant -f project.xml.
- Split the copy and compress (like in dist-jar target) to two
different targets. I had to do this in project.xml to be able to
override the compress easily. If you do this split in the default
build.xml instead, the project.xml override needs a lot less
overriding definitions."
>
> The good news is that the PdfPlugin viewer seems to work perfectly on
> FF and Chrome. In Chrome it looks nice, and I really like the top bar
> and the addition of the View in Browser button. That really helps.
>
> Likewise the iframe viewer works well for plain text. For HTML it
> displays the mark-up rather than rendering it in the browser, so I'd
> like to investigate that a bit more.
Erik has answered this one here:
https://forums.alfresco.com/en/viewtopic.php?f=48&t=43212
So for html there needs to be another approach.
>
> PdfJs is also working, but I refactored it slightly, removing the
> custom Surf page and instead using the URL of the pdviewerform.get
> webscript directly. I updated the URL path in line 143 of PdfJs.js,
> and also applied the encodeURIComponent() function to the URL
> parameters used (file and htmlid, the latter being referenced in the
> web script) since the web script runtime was throwing errors with the
> unescaped content URL being passed as a parameter. It seems to work
> fine with those changes.
>
> I'd would still like to make a couple more changes to this latter
> plugin, though, having understood it a bit better now (I think). I'd
> like to get rid of the iframe, as the example code on jsbin.com[1]
> seems to avoid this and just loads the PDF directly. I see the web
> script is useful for defining the form markup, so I would keep this
> but try loading it via XHR (instead of frame) and inject it into the
> plugin <div> on the page. I would also make the buttons more YUI-like,
> as this could be a really good example of an advanced
> JavaScript-driven viewer, but just needs to fit in a bit better
> stylistically, but also to use YUI Events hooked up to plugin class
> methods, rather than explicit onclick attributes on the button
> elements.
For button styling, I've done some updates for that already, using
Share icons instead of pdf.js default ones. And some css styling. But
can probably be styled even more.
The reason I did it as iframe was path of least resistance. It almost
worked out of the box. But I agree, it can probably bee embedded with
markup instead. What needs to be done there is find a better way to
overload the pdfjs/pdfviewer.js and how to load the pdf. Now it loads
with an window load event.
The pdfviewer.js is the only pdf.js source file that has changes
needed for our purpose. I've clearly marked them with "ShareExtras
Changes Start/End". So those changes needs to be reviewed, and
possibly find a better way to override, but the coding style doesn't
allow for easy override lets say from a separate prototype js file.
There is also a 'use strict' requirement for pdf.js, I'm not sure how
that would affect other js code if loaded in the same window context.
>
> Let me know if you can see any reasons why this won't work, otherwise
> I'll start taking a look at this.
As per out previous discussions around PdfPlugin, I merged the iFrame
and PdfPlugin to "Embed". Reason was that they essentially do the
same. I committed those changes to Sandbox/Viewer Extension for
review.
So now you can use the Embed for
<condition mimeType="text/plain">
<plugin skipplugintest="true">Embed</plugin>
</condition>
<condition mimeType="application/example">
<plugin IEactiveX="Example.ActiveX"
PluginMimetype="application/example">Embed</plugin>
</condition>
The first one just skips plugins tests and embedds in iframe, suitable
for plain/text. skipplugintest can of course be used by an admin that
knows it will just work for that mimetype.
The second one is if you have a special plugin you want to use. You
have to supply both the test to use for IE and the PluginMimetype,
giving the mimetype again may seen redundant, but was easier since the
preview base code has built in support for attributes ovverride,
didn't look into if you could fetch the mimeType from condition.
The default config is to use "Embed" to test for pdf plugins.
>
> Cheers,
> Will.
>
> [1] http://jsbin.com/pdfjs-helloworld/edit#html,live
Cheers,
Peter
Erik Winlöf
> Likewise the iframe viewer works well for plain text. For HTML itErik has answered this one here:
> displays the mark-up rather than rendering it in the browser, so I'd
> like to investigate that a bit more.
https://forums.alfresco.com/en/viewtopic.php?f=48&t=43212
So for html there needs to be another approach.
Will Abson
> 2012/4/24 Will Abson <will....@gmail.com>:
>> I completed the merge this morning with r1052 and r1053.
>>
>> The module builds perfectly with the project.xml build script, but I
>> did see there is a lot of additional/overridden targets in this file.
>> I'd like to understand why that is, ideally project.xml would contain
>> just a few extra lines but perhaps changes are needed in build.xml to
>> make it more modular. But let's park that for now as it's more
>> important to get the plugins working as well as they can.
>
> Quoting myself from earlier in this discussion:
>
> "I've change and committed to use the same build.xml as in Media
> Preview, with a project.xml override.
> Two things I noticed from this exercise
> - Maybe flip what loads what, make project.xml the default one, and
> build.xml the override one. Reason for this is that if you just type
> ant, it will load the build.xml and get a successful build, but the
> resulting jar will be broken due to the yuicompressor bug. You can of
> course have it in the build instructions to use ant -f project.xml.
> - Split the copy and compress (like in dist-jar target) to two
> different targets. I had to do this in project.xml to be able to
> override the compress easily. If you do this split in the default
> build.xml instead, the project.xml override needs a lot less
> overriding definitions."
Thanks, I missed your second point about the splitting of projects. I
entirely agree, so will look at that.
>>
>> The good news is that the PdfPlugin viewer seems to work perfectly on
>> FF and Chrome. In Chrome it looks nice, and I really like the top bar
>> and the addition of the View in Browser button. That really helps.
>>
>> Likewise the iframe viewer works well for plain text. For HTML it
>> displays the mark-up rather than rendering it in the browser, so I'd
>> like to investigate that a bit more.
>
> Erik has answered this one here:
> https://forums.alfresco.com/en/viewtopic.php?f=48&t=43212
>
> So for html there needs to be another approach.
As Erik mentioned Kev has suggested that a better solution is in the
pipeline, so let's just document it as a known issue for now and
revisit it later.
Quite reasonable and it works well. Is there a public example or
tutorial somewhere that you followed, then? The only ones I could find
were the jsbin examples, which take the slightly different approach I
outlined.
> As per out previous discussions around PdfPlugin, I merged the iFrame
> and PdfPlugin to "Embed". Reason was that they essentially do the
> same. I committed those changes to Sandbox/Viewer Extension for
> review.
Sounds reasonable, if it reduces complexity of course I'm in favour.
Can you make the same change in Media Previews?
> So now you can use the Embed for
> <condition mimeType="text/plain">
> <plugin skipplugintest="true">Embed</plugin>
> </condition>
>
> <condition mimeType="application/example">
> <plugin IEactiveX="Example.ActiveX"
> PluginMimetype="application/example">Embed</plugin>
> </condition>
>
> The first one just skips plugins tests and embedds in iframe, suitable
> for plain/text. skipplugintest can of course be used by an admin that
> knows it will just work for that mimetype.
I wonder if it would make more sense to assume skipplugintest=true as
the default (i.e. if not specified)? It seems more intuitive to me
that the plugin should just do the embed without any checks, since
most content (text, HTML, XML, etc.) will not require a plugin, and it
is just PDF that does.
> The second one is if you have a special plugin you want to use. You
> have to supply both the test to use for IE and the PluginMimetype,
> giving the mimetype again may seen redundant, but was easier since the
> preview base code has built in support for attributes ovverride,
> didn't look into if you could fetch the mimeType from condition.
With a WebPreview plugin you can get the condition mimetype using
this.wp.options.mimeType. So you should be able to remove that
attribute, I think.
Cheers,
Will
Erik Winlöf
gpulido
First of all, I would like to apologize if this is not the correct
place to ask. (Please point me to the correct place)
I'm trying to test the MediaPreviewer or the ViewerExtension, and I'm
not capable of make it work. Please tell me if I'm doing something
wrong:
-I have an alfresco 4.0.d installed over a Windows Server 2008.
- I downloaded the source code for the MediaPreviewer and the
ViewerExtension using svn.
- I downloaded and installed apache ant on the server
- Under the MediaPreviewer folder I run ant -f project.xml, it
generates a jar file (media-preview-2.0-dev.jar) under the dist
folder. I copied that file to the tomcat/shared/lib folder.
- I also create the web-preview.get.config.xml under the tomcat/shared/
classes/alfresco/web-extension/site-webscripts/org/alfresco/components/
preview folder. I use the viewerExtension config sample. I modified it
to just use the pdfplugin instead of the pdf.js. So I just have the
following:
<!-- Share Extras Viewer Start Add -->
<condition mimeType="text/plain">
<plugin>IframeView</plugin>
</condition>
<condition mimeType="application/pdf">
<plugin>PdfPlugin</plugin>
</condition>
<condition mimeType="application/pdf">
<plugin>PdfPlugin</plugin>
</condition>
<!-- Share Extras Viewer End Add -->
-I restarted the alfresco server. Tried to preview a pdf on Chrome and
Firefox (I have the adobe acrobat plugin installed) And it doesn't
load any kind of preview. It just shows the message it shows before
the preview is created: "preparando la visualización" in spanish. It
could be translated as "creating the preview".
-When I review the web-preview.js, on the line:
227 plugin = new
Alfresco.WebPreview.prototype.Plugins[pluginDescriptor.name](this,
pluginDescriptor.attributes);
the new Alfresco.WebPreview.prototype.Plugins that are loaded are only
those that are on the tomcat\webapps\share\components\preview folder,
and it doesn't load any of the new preview plugins.
If I use the information of the blog
http://blogs.alfresco.com/wp/wabson/2012/04/11/share-document-previews-in-alfresco-4
to manually add the plugins to the preview folder, and manually modify
the template tomcat\webapps\share\WEB-INF\classes\alfresco\site-
webscripts\org\alfresco\components\preview\web-preview.get.head.ftl to
load them, then I'm capable of preview the pdf using the pdfplugin.
Am I missing something? I have the same issue if I use the
ViewerExtension code. No plugins are loaded.
Thank you in advance
Gabriel Pulido
On 25 abr, 17:07, Erik Winlöf <erik.win...@gmail.com> wrote:
> Kev has now implemented a fix for the "mimeType" issue, and it has been
> resolved for Alfresco Enterprise 4.0.2 and Community HEAD (rev
> 35696). Cheers for reminding us about that response Peter!
>
>
>
>
>
>
>
> On Wed, Apr 25, 2012 at 1:54 PM, Will Abson <will.ab...@gmail.com> wrote:
> > On 25 April 2012 08:27, Peter Löfgren <pe...@loftux.se> wrote:
Peter Löfgren
> First of all, I would like to apologize if this is not the correct
> place to ask. (Please point me to the correct place)
before release.
....
> Am I missing something? I have the same issue if I use the
> ViewerExtension code. No plugins are loaded.
http://<servername>/share/service/modules/deploy ?
You need to activate the viewers you have enabled in your config.
Pleas note that shortly the iFrame and PdfPlugin will be replaced by
Embed, so next time you update you have to redo the module deploy.
>
> Thank you in advance
> Gabriel Pulido
>
Peter
Will Abson
On 27 April 2012 09:18, gpulido <gabriel.pul...@gmail.com> wrote:
> Hello,
> First of all, I would like to apologize if this is not the correct
> place to ask. (Please point me to the correct place)
additional hands to help test out new changes like this.
> -I restarted the alfresco server. Tried to preview a pdf on Chrome and
> Firefox (I have the adobe acrobat plugin installed) And it doesn't
> load any kind of preview. It just shows the message it shows before
> the preview is created: "preparando la visualización" in spanish. It
> could be translated as "creating the preview".
>
> -When I review the web-preview.js, on the line:
>
> 227 plugin = new
> Alfresco.WebPreview.prototype.Plugins[pluginDescriptor.name](this,
> pluginDescriptor.attributes);
https://issues.alfresco.com/jira/browse/ALF-12798. It seems if the
client-side components are not loaded then the previewer throws this
error. Arguably Share should handle that better, but the cause as you
mention is that the client-side files are obviously not being loaded.
> the new Alfresco.WebPreview.prototype.Plugins that are loaded are only
> those that are on the tomcat\webapps\share\components\preview folder,
> and it doesn't load any of the new preview plugins.
so that would be the first place to check.
Cheers,
Will
gpulido
you were right, I forget to deploy the module, sorry for the silly
question :(
Now it works correctly, I'll test it and give feedback asap
Great work!!!
Best regards
Gabriel
On 27 abr, 12:15, Peter Löfgren <pe...@loftux.se> wrote:
> 2012/4/27 gpulido <gabriel.pulidodetor...@gmail.com>:
Peter Löfgren
>
> custom Surf page and instead using the URL of the pdviewerform.get
> webscript directly. I updated the URL path in line 143 of PdfJs.js,
> and also applied the encodeURIComponent() function to the URL
> parameters used (file and htmlid, the latter being referenced in the
> web script) since the web script runtime was throwing errors with the
> unescaped content URL being passed as a parameter. It seems to work
> fine with those changes.
Alfresco.util.message for a I18N message loading indicator. So there
is a dependency on alfresco.js, that dependes on yui. Adding
alfresco.js is easy, but the yui library is a lot of components if in
debug mode. There also doesn't seem to be a freemarker include that
can be used easily for this. I removed that message, since the text
information is somewhat redundant as there is a graphic progress
indicator. Also fixed a small issue with zoom button alignment.
The pdf.js project has completely rewritten the looks of the viewer.
See http://mozilla.github.com/pdf.js/web/viewer.html
I think this look is cleaner, and use css styling more extensively,
graphic buttons are now css references. The dark theme doesn't in my
opinion fit with Share looks, but it should be easy to change.
I guess what I'm saying here is that I think it is good if we follow
the basic layout of pdf.js viewer, and then just change css styling. I
will try to implement this new viewer looks, but if we have someone
that is good att css styling, please help out here.
There is one thing holding this back right now, the current HEAD of
pdf.js has broken support for Safari
https://github.com/mozilla/pdf.js/issues/1627
>>
>> Cheers,
>> Will
How should we proceed with documentation? Will, can you start with
some basic outlined document(s) where i can add information where
relevant?
Cheers,
Peter Löfgren
Will Abson
> This change introduced one error. In pdfviewer.js I used
> Alfresco.util.message for a I18N message loading indicator. So there
> is a dependency on alfresco.js, that dependes on yui. Adding
> alfresco.js is easy, but the yui library is a lot of components if in
> debug mode. There also doesn't seem to be a freemarker include that
> can be used easily for this. I removed that message, since the text
> information is somewhat redundant as there is a graphic progress
> indicator. Also fixed a small issue with zoom button alignment.
> The pdf.js project has completely rewritten the looks of the viewer.
> See http://mozilla.github.com/pdf.js/web/viewer.html
> I think this look is cleaner, and use css styling more extensively,
> graphic buttons are now css references. The dark theme doesn't in my
> opinion fit with Share looks, but it should be easy to change.
> I guess what I'm saying here is that I think it is good if we follow
> the basic layout of pdf.js viewer, and then just change css styling. I
> will try to implement this new viewer looks, but if we have someone
> that is good att css styling, please help out here.
> There is one thing holding this back right now, the current HEAD of
> pdf.js has broken support for Safari
> https://github.com/mozilla/pdf.js/issues/1627
version. I like the new sidebar in particular, much better than the
last one.
However, I did start removing the dependency on pdfviewer.js as I
think I mentioned, so I (almost) now have a working prototype that
drives pdf.js directlty from the plugin class.
I've had to reimplement some code from pdfviewer in the plugin, but it
means we can use Alfresco/YUI functions and utilities, which helps in
reducing the code size as well as making the viewer feel more
'integrated' as you say.
I'll check in what I have later today, so you can try it out.
Currently the iframe/pdfviewer impl is used by default, and my native
version using a custom switch in the web-preview config. But I may
suggest making the latter the default if it can be proved to work, as
I've concerns around the maintainability of pdfviewer given its poor
code style, lack of inline docs and many points where you needed to
make changes.
> How should we proceed with documentation? Will, can you start with
> some basic outlined document(s) where i can add information where
> relevant?
README.txt as the authoritative guide to the add-on, and if we use
MarkDown syntax then we can easily convert it to HTML for the wiki.
I've done a bad job in my projects keeping the two in sync, so I'd
suggest for this one we try this new approach if you agree?
It's not a problem to add some basic docs from my perspective, but let
me know if you're thinking of something more specific :-)
Cheers,
Will
Will Abson
the following config in web-preview.get.config.xml
<!-- PdfJS viewer for PDF -->
<condition mimeType="application/pdf">
<plugin mode="block">PdfJs</plugin>
</condition>
<!-- PdfJS viewer for documents that can be converted to pdf -->
<condition thumbnail="pdf">
<plugin src="pdf" mode="block">PdfJs</plugin>
</condition>
It's largely similar to pdfviewer.js but I introduced a change that
allows pages to flow across the preview area horizontally using a left
float. Try viewing a PPT presentation at 25% zoom and you should see
the effect.
Comments are welcome but I'm aware the Full page button doesn't yet
work properly, as I need to do some further research on how to do this
properly in JavaScript. Also I've only tested in Firefox so far, but I
will try with Chrome later this week. Oh, and the text layer that
allows you to select text is not yet being drawn, but it's first on
the to-do list, just before a text search capability :-)
It shouldn't have broken anything in the existing iframe
implementation, but if you see any problems let me know...
Cheers,
Will
Peter Löfgren
> the following config in web-preview.get.config.xml
>
> <!-- PdfJS viewer for PDF -->
> <condition mimeType="application/pdf">
> <plugin mode="block">PdfJs</plugin>
> </condition>
>
> <!-- PdfJS viewer for documents that can be converted to pdf -->
> <condition thumbnail="pdf">
> <plugin src="pdf" mode="block">PdfJs</plugin>
> </condition>
>
> It's largely similar to pdfviewer.js but I introduced a change that
> allows pages to flow across the preview area horizontally using a left
> float. Try viewing a PPT presentation at 25% zoom and you should see
> the effect.
>
> Comments are welcome but I'm aware the Full page button doesn't yet
> work properly, as I need to do some further research on how to do this
> properly in JavaScript. Also I've only tested in Firefox so far, but I
> will try with Chrome later this week. Oh, and the text layer that
> allows you to select text is not yet being drawn, but it's first on
> the to-do list, just before a text search capability :-)
>
> It shouldn't have broken anything in the existing iframe
> implementation, but if you see any problems let me know...
>
> Cheers,
> Will
>
The flow of multiple pages with smaller zoom or resizing the browser
is really the way to go.
Considering that their own viewer.js handler code is more than 1500
rows there may be some more to implement, but we do not need to be on
par, the default pdf.js viewer is being implemented to be used as a
plugin in firefox. So lots of that code is not necessary. But if we
get text layer, sidebar with index and thumbnails, then it is feature
complete i think. The default pdf.js viewer also use local storage, so
when you view the same file again it remembers your zoom level and at
what page you were viewing last. Sidebar thumbnails ar quite slow to
render, so maybe just sidebar index if available.
Only issue I've noticed is that if you are at say page 10 of 20, when
you change zoom to 25%, all pages prior to page 10 are blank. But as
soon as you start stepping back pages they render.
TO my understanding, the file pdfviewercompatibility.js checks for
availability of native functions, if not present it creates them. It
can be useful/necessary to support wider range of browsers.
I think we should focus on your version now. Since you may already be
working on more viewer stuff let me know where i can help.
>>> How should we proceed with documentation? Will, can you start with
>>> some basic outlined document(s) where i can add information where
>>> relevant?
>>
>> What sort of documentation do you mean? Generally I'd suggest we use
>> README.txt as the authoritative guide to the add-on, and if we use
>> MarkDown syntax then we can easily convert it to HTML for the wiki.
>> I've done a bad job in my projects keeping the two in sync, so I'd
>> suggest for this one we try this new approach if you agree?
>>
>> It's not a problem to add some basic docs from my perspective, but let
>> me know if you're thinking of something more specific :-)
>>
>> Cheers,
>> Will
>
Cheers,
Peter
Will Abson
On 3 May 2012 19:19, Peter Löfgren <pe...@loftux.se> wrote:
> The flow of multiple pages with smaller zoom or resizing the browser
> is really the way to go.
default zoom level to 'Two page fit' (I augmented the levels that were
there already) I think the default view of a document like this works
well, having tested with PDF, PPT(X) and DOC(X).
> Considering that their own viewer.js handler code is more than 1500
> rows there may be some more to implement, but we do not need to be on
> par, the default pdf.js viewer is being implemented to be used as a
> plugin in firefox. So lots of that code is not necessary. But if we
> get text layer, sidebar with index and thumbnails, then it is feature
> complete i think. The default pdf.js viewer also use local storage, so
> when you view the same file again it remembers your zoom level and at
> what page you were viewing last. Sidebar thumbnails ar quite slow to
> render, so maybe just sidebar index if available.
controls work better. I'm pretty happy with the viewer now, at least
in Firefox.
I agree the text layer is a must, but it might involve refactoring the
rendering to make it a bit more efficient, since I suspect it will add
a bit to the processing. It's next on the list, anyway.
A sidebar would be helpful too, I agree. Index could go in there, plus
text search, and thumbnails later on. But since the Flash previewer
does not have these features, I'm inclined to push out the 2.0 release
without those, and add them in for 2.1. What do you think?
Local storage would be cool, too. I think it would be great if we
could remember the page number and zoom level of specific documents,
and I don't think it would be too much work. A related feature could
be a 'link to slide' button, which appends some hash info to the
document-details URL, used to highlight a specific slide when the page
is opened. Maybe just do-able for 2.0.
> Only issue I've noticed is that if you are at say page 10 of 20, when
> you change zoom to 25%, all pages prior to page 10 are blank. But as
> soon as you start stepping back pages they render.
introduce that bug when changing zoom levels, as you noticed. I've
modified the rendering to always start checking from the first page
now, so that shouldn't happen any more.
> TO my understanding, the file pdfviewercompatibility.js checks for
> availability of native functions, if not present it creates them. It
> can be useful/necessary to support wider range of browsers.
reasonably cross-platform. But I know there are issues with
compatibility due to having only tested in Firefox. If you have time
to fix any such issues you find, or at least flag them, that would be
helpful.
> I think we should focus on your version now. Since you may already be
> working on more viewer stuff let me know where i can help.
may need to do this before we release. That would be really useful if
you get time, but I did look the other day and it seems they've
changed the callback structure needed when loading the PDF.
Plus compatibility stands out as a major issue. I gave Mike F a
current snapshot this week and he highlighted severe font problems in
Chrome, and IE9 not working at all.
Cheers,
Will
Erik Winlöf
Local storage would be cool, too. I think it would be great if we
could remember the page number and zoom level of specific documents,
and I don't think it would be too much work. A related feature could
be a 'link to slide' button, which appends some hash info to the
document-details URL, used to highlight a specific slide when the page
is opened. Maybe just do-able for 2.0.
Peter Löfgren
...
> I've not investigated updating to the latest pdf.js, but I think we
> may need to do this before we release. That would be really useful if
> you get time, but I did look the other day and it seems they've
> changed the callback structure needed when loading the PDF.
>
> Plus compatibility stands out as a major issue. I gave Mike F a
> current snapshot this week and he highlighted severe font problems in
> Chrome, and IE9 not working at all.
>
> Cheers,
> Will
I've updated to the latest version of pdf.js and refactored your
non-iframe code to use the new way of loading pdf:s. My testing says
it should be working as before, but it could be worth testing.
The iframe variant is also updated, now it is as close to original as
possible. Think we can keep it that way and for now keep it as a
reference, and dev efforts should be for non-iframe version.
IE9 support as you mentioned is broken, the pdf.js project has some
merge requests pending. I'll commit those updates when the become
available. It should be fairly easy now if the pdf.js project does not
refactor their api again.
Cheers,
Peter
Peter Löfgren
> merge requests pending. I'll commit those updates when the become
> available. It should be fairly easy now if the pdf.js project does not
> refactor their api again.
>
> Cheers,
> Peter
testing says IE9 is working.
Peter
Will Abson
On 17 May 2012 15:51, Peter Löfgren <pe...@loftux.se> wrote:
> I've updated to the latest version of pdf.js and refactored your
> non-iframe code to use the new way of loading pdf:s. My testing says
> it should be working as before, but it could be worth testing.
> The iframe variant is also updated, now it is as close to original as
> possible. Think we can keep it that way and for now keep it as a
> reference, and dev efforts should be for non-iframe version.
doing that!
I've now added in initial text layer support, which is enabled by
default but can be disabled by setting disableTextLayer="true" in the
plugin config. Also while I was at it I made 'block' (or non-iframe)
mode the default display type, since we are agreed we should focus on
this now.
> IE9 support as you mentioned is broken, the pdf.js project has some
> merge requests pending. I'll commit those updates when the become
> available. It should be fairly easy now if the pdf.js project does not
> refactor their api again.
I'll have to trust you :-). I'm switching to Mac OS soon, so I'll find
a solution then. But I did notice that the fonts are still screwy on
Chrome, do you see that on your client?
Cheers,
Will
Will Abson
> I can't test with IE9 as it's not supported on my XP install here, so
> I'll have to trust you :-). I'm switching to Mac OS soon, so I'll find
> a solution then. But I did notice that the fonts are still screwy on
> Chrome, do you see that on your client?
upstream to the Chromium guys.
https://github.com/mozilla/pdf.js/issues/1689
It seems it may also affect Opera. Until the bug is fixed, we should
assume that all content converted via OpenOffice will not render
correctly in these browsers. I'd suggest we add a test for this in the
report() method, if nobody objects I will go ahead and implement this.
Cheers,
Will
Peter Löfgren
confirmed with ver 20, assuming it will be fixed for 21) and on
Windows, and with src pdf, then report it cannot be used.
Maybe a less than version test can be added later when we know in
which version it is fixed. Anyway, Chrome on Mac works perfectly.
Peter
Will Abson
chromium project bug indicates this version is also affected). I will
add an upper limit should it get fixed in a future version, but as of
yet it hasn't been assigned to a developer.
Cheers,
Will