Swiffy runtime.js huge file size - google-swiffy

I'm using google swiffy, and it require to embed "runtime.js".
which is very huge file... size about 410KB.
I'm using v7.3.0 version...
Is there any earlier smaller versions...
or other alternatives.
Thanx

You don't need to embed runtime.js - just link to it from your html, like this:
<script src="https://www.gstatic.com/swiffy/v7.3.0/runtime.js"></script>
That link should already be in your swiffy HTML file.
But, if by "embed" you meant "link to", Google's servers deliver the runtime fast, so the size shouldn't be an issue. But if it is, you could try linking to an older, smaller version of the runtime (e.g. version 5.2.0 is 280K). But then, an older version might not render your swiffy correctly.

Related

Label Image scale issue in Codename one library 3.3

We are using the following code to download image from our server and display it with a label:
ImageDownloadService.createImageToStorage(IconSrc, label, IconSrc,
new Dimension(width,height), ImageDownloadService.PRIORITY_NORMAL);
After upgrading to the latest library 3.3, theimages are no longer scaled properly. It either only shows one corner of the image or scales the image up to fill the entire space.
This issue does not occur once I fall back to the older library 3.2.
Looking at the code of ImageDownloadService I don't quite understand how this functionality worked in the past.
We don't really use that class internally and have recommended that developers migrate to the far superior URLImage class. I'll have a look at trying to fix that regression but I'd strongly suggest you migrate your code to the newer API.

Wkhtmltopdf version, first page and TOC

Some questions for this very nifty tool, unfortunately lacking many usage examples.
Manual speaks of a possible “Reduced Functionality” for wkhtmltopdf. I have version wkhtmltox-0.11.0_rc1-installer.exe, by running wkhtmltopdf --version what should I read to understand whether my version is the reduced one or not?
Currently I like wkhtmltopdf for webpages I want to read later and/or store. To mirror webpages I use httrack, then I generate the PDF with wkhtmltopdf *.html offline.pdf. How can I set/specify the first PDF page from the *.html list? Currently they seem to be converted in alphabetical order.
If I run wkhtmltopdf toc http://qt-project.org/doc/qt-4.8/qstring.html qstring.pdf I simply get a leading blank page, no TOC. What’s wrong?
Thanks for helping
EDIT:
#Nenotlep:
Your TOC trick works perfectly.
As for the first page, I don’t need an actual cover.
What I need is a way to download/convert a given page www.site.com/foo.html and all the linked pages (A.html, B.html ...) up to a certain depth level. Then I want a single PDF starting with foo.html and containing also the pages A.html, B.html ... (with relative links).
I don’t think there is an option to download and insert the linked pages in the final PDF (please, correct me if I am wrong). So I use httrack.com to download and wkhtmltopdf to convert. Given the alphabetical behaviour of wkhtmltopdf, the best now seems to rename the target page, downloaded with httrack, something like !foo.html.
Please, let me know of possible alternatives.
For part 3 of the question which is blank TOC, the latest stable version 0.12.5 also does not generate it. The pre-release version 0.12.6-dev has fixed this problem in Mac.
I think all available precompiled wkhtmltopdf's are compiled with the patched QT, they are not reduced. The reduced functionality means that it was compiled without a special patched version of QT. I use the windows version and it isn't reduced.
I think the cover command line argument would work for you. I can't test at the moment, but try a command like wkhtmltopdf cover derpy.html toc --xsl-style-sheet default.xsl rarity.html twilight.html spike.html equestriadaily.pdf
At least in Linux, I think the asterix *.html simply explodes into all the html files before the command is performed, so if you select one html file for the cover and then do *.html in the same folder you will get the file twice. Getting around this issue might need some command line sorcery or a batch file or some other trickery.
This is a bug in wkhtmltopdf. The workaround is to manually set a tocfile. You can get the default tocfile with wkhtmltopdf.exe --dump-default-toc-xsl. Then you can save the output as a file and use it like wkhtmltopdf.exe toc --xsl-style-sheet default.xsl www.stackoverflow.com so.pdf.

Internal links with wkhtmltopdf?

I have created a PDF from several web pages using wkhtmltopdf.
Is there a way to link across pages, for example from page 10 to 15.
I tried creating an element with an ID and then an anchor to link to it, but this does not work within the same page or across pages. It turns the link into an absolute URL and tries to open it in a web browser.
I solved this issue by updating the binary that I was using.
I was using 0.8 and switched to 0.11.0 rc1.
Ensure that it is built against QT (the latest binary at http://code.google.com/p/wkhtmltopdf/downloads/detail?name=wkhtmltoimage-0.11.0_rc1-static-amd64.tar.bz2 is.
And then just to be sure enable internal links:
--enable-internal-links
when you call the conversion
i had this issue after installing pathced version of QT
i had wkhtmltopdf 0.9.6, than i also switched to 0.11.0 rc1
then worked fine!
and no need to use --enable-internal-links. you can just turn off this option by --disable-internal-links* by default its on.
Internal links appear only to work correctly in certain builds for certain platforms. With the latest WkHTMLtoPDF 0.12.5 releases the unix builds are OK (at least for Centos and Ubuntu) and internal links are generated correctly BUT windows builds DO NOT work and leave broken links. I don't know why this is and have commented on GitHub accordingly.
Also when multiple html input documents are used any 'internal' hyperlinks between these are broken (all platforms). In other words cross input document links are NOT fixed up. This would be a really useful feature addition (particularly when generating massive reports) but sadly does not appear to be supported as yet.

compressed / minified prototype file

I need a compressed minified prototype file.
Can anyone help me?
Thanks
As far as I'm aware, there's no official or hosted minified build of Prototype. You can run it through jsmin easily enough, but then you have to host it yourself. Or as Tomasz pointed out, you can use the unminified (but gzipped) version from Google's CDN.
Google does not hurt: http://prototypejs.org/2008/05/27/prototype-hosted-on-google-s-servers
(corrected link)
FWIW, I ran prototype.js (v. 1.6) through UglifyJS using http://jscompress.com/, and started getting a bunch of javascript errors. So Google is clearly the way to go.
I found the solution and minimized this file, it went from 130mb to 67 mb. Although I did very minimal testing, everything works on my end with no firebug errors. Please Let me know how it works on your scripts.
Heres the link!
You have to upload the entire file on the right hand side.
http://shrinksafe.dojotoolkit.org/

additional settings for wkhtmltopdf?

I am converting some docs to pdf using wkhtmltopdf (currently using perl and the command line versions). Is it possible to change the "PDF Producer", "PDF Version" and "Fast Web View" fields? The current defaults are "wkhtmltopdf", "1.4 (Acrobat 5.x)", and "No", respectively. I didn't see anything in the wiki page
Pass the following with the command line to see supported features: " --extended-help"
Not sure if those specific params are supported or not.
I patched wkhtmltopdf to support an additional flag recently, and it would be quite easy to add parameters to change those. I don't believe they are supported currently, though.
PDF Producer: Nope. Most apps want folks to know that particular app generated the PDF.
PDF Version: Nope, but trivial. The version number at the beginning of the file is just a courtesy really. What exactly are you after with this? Chances are you don't really need it. The PDF generated isn't going to acquire any features automagically just because the PDF claims to be this version or that. It's only really used so a viewer opening a newer PDF can say something like "I don't support this version, some stuff might not work". Because everything will work regardless (unless someone happens to have a VERY old version of Acrobat/Reader), I don't see the issue.
Fast Web View: Nope, and decidedly non-trivial. "Fast Web View" means everything needed to display the first page of the PDF is sorted to the front of the file, and there are various "hints" on where an app downloading the PDF can find this or that. It's not just a flag, not by a long stretch.
Zero for three. Sorry.

Resources