cant open base64 encoded pdf files

[TiMeZoNe]

hi there,

I used the Clientbundle with DataResource for PDFs.
Some smaller PDF files are encoded in base64. However, when you click
on the link to the encoded files, the browser produces a blank page.

The Uibinder code looks like this:

<g:Anchor href="{bundle.my_fancy_pdf.getUrl}" target="_blank"
addStyleNames="{bundle.style.pdfLink}">My fancy pdf</ g: Anchor>

I have already tried I Frames and similar tricks, but unfortunately
that doesn't help either.

A live example can be found here:
http://www.haus-und-grund-halle.de/

In the menu (Sorry, it's a German site ;) ) follow the links:
"Eigentümerservice" -> "Informationsblätter" -> "Mietsicherheit bei
der Vermietung von Wohnraum"

Does anyone have any idea what the problem could be? I've tested this
on multiple computers with multiple browsers.

Is there a trivial way to tell the Resource Generator to stop the
base64 encoding?

thanks

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Viliam Durina]

It works for me in Firefox 3.5, but not in IE8 or chrome 5 beta.

I think that you dont have to use ClientBundle: ClientBundle is for
optimising when there are many resources on one page (mostly images)
and all could be downloaded in one roundtrip. In your case, the user
always gets the documents by one, so one roundtrip is needed anyway.
The only benefit of ClientBundle is that filename changes
automatically when the document is updated.

I don't see annotation or anything in the API to disable inlining of
some resource. If there really isn't any, I think you should file a
bug.

Viliam

[Sripathi Krishnan]

The only benefit of ClientBundle is that filename changes
automatically when the document is updated.

That's the whole idea of DataResource - you can set aggressive cache headers to reduce the load on your servers.

IE8 has the 32KB limit on data:uri .. may be thats the issue. Or perhaps some PDF renderers don't understand data:uri.

I also looked at the code and couldn't find a way to disable inlining of DataResource. I tend to agree its a bug..

--Sri

[Viliam Durina]

> That's the whole idea of DataResource - you can set aggressive cache headers
> to reduce the load on your servers.

But another feature I don't like about this is, that when you save the
file, it has a strange name. And the file with data: uri even
stranger, different each time you save it (e.g. Oo0X7cbg.pdf.part, not
even with PDF extension). I use only ImageResources, primarily because
many images are loaded in a single larger one. I achieve the caching
thing of downloaded documents by adding ?hash=xxxxx to the URL. The
resource is statically placed on the web root directory and the HTTP
server will serve it from there ignoring characters after the question
marks - these are for browser to know that it is a different file when
caching is enabled. After save, the file is named without the question
mark and characters after it.

And secondly, the data:uri is optimization not needed in this use
case: suppose you have hundreds of documents that the GWT compiler
decides to inline as data: URI. The script will get very large, will
have to be downloaded, but only few users will actually need to view
the document. And after recompile, another large script will be
downloaded. If you used the approach I mentioned above, their hash
will not change during each compile and will not be downloaded at all,
if the user does not click that link. Inlining is good, if the user
accesses that resource in most use case scenarios.

> IE8 has the 32KB limit on data:uri .. may be thats the issue. Or perhaps
> some PDF renderers don't understand data:uri.

This particular file has 44kB, and all other there have over 32kB.
Maybe, Hendrik, you should test with smaller PDF if it works in IE.

> I also looked at the code and couldn't find a way to disable inlining of
> DataResource. I tend to agree its a bug..

[dolc...@gmail.com]

That .part extension is probably because your browser is still
downloading the pdf?

[TiMeZoNe]

I've now written a quick'n'dirty patch ;)

works fine for DataResources. :)

### Eclipse Workspace Patch 1.0
#P GWT_SOURCE
Index: user/src/com/google/gwt/resources/client/ClientBundle.java
===================================================================
--- user/src/com/google/gwt/resources/client/ClientBundle.java
(revision 7991)
+++ user/src/com/google/gwt/resources/client/ClientBundle.java
(working copy)
@@ -37,9 +37,13 @@
* Specifies the classpath location of the resource or resources
associated
* with the {@link ResourcePrototype}.
*/
- @Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Source {
String[] value();
}
+
+ @Retention(RetentionPolicy.RUNTIME)
+ @Target(ElementType.METHOD)
+ public @interface SkipBase64 {
+ }
}
Index: user/src/com/google/gwt/resources/rg/DataResourceGenerator.java
===================================================================
--- user/src/com/google/gwt/resources/rg/DataResourceGenerator.java
(revision 7991)
+++ user/src/com/google/gwt/resources/rg/DataResourceGenerator.java
(working copy)
@@ -19,6 +19,7 @@
import com.google.gwt.core.ext.UnableToCompleteException;
import com.google.gwt.core.ext.typeinfo.JMethod;
import com.google.gwt.resources.client.DataResource;
+import com.google.gwt.resources.client.ClientBundle.SkipBase64;
import com.google.gwt.resources.ext.AbstractResourceGenerator;
import com.google.gwt.resources.ext.ResourceContext;
import com.google.gwt.resources.ext.ResourceGeneratorUtil;
@@ -45,7 +46,12 @@
}

URL resource = resources[0];
- String outputUrlExpression = context.deploy(resource, false);
+ String outputUrlExpression;
+ if (method.getAnnotation(SkipBase64.class) != null) {
+ outputUrlExpression = context.deploy(resource, true);
+ } else {
+ outputUrlExpression = context.deploy(resource, false);
+ }

SourceWriter sw = new StringSourceWriter();
// Write the expression to create the subtype.

[Viliam Durina]

No, the download was complete, after renaming the file was opened
correctly. Maybe it's a bug in firefox.
V.

On 28. Apr, 18:32 h., "dolcra...@gmail.com" <dolcra...@gmail.com>
wrote:

[Viliam Durina]

You should file this as a bug, eventually enhanced with ability to
disable inlining for the whole file, not for each individual item.
Viliam

[TiMeZoNe]

http://code.google.com/p/google-web-toolkit/issues/detail?id=4895

done :)