I often "print" some webpages into pdf files. Therefore I created an own stylesheet for that webpages so I have only the text I need (I'm using the addon stylish for it).
The problem: If I save the page to a pdf file, it becomes relatively huge. Example: I copied the text to LibreOffice and exported it to a pdf file. The result: about 100kb. With Firefox: 1.8 MB!! And it's only text! (I need that small smize, because I have to email the files)
Does anyone know how I can reduce those files? Maybe with ghostscript or any other commandline-tool?
EDIT:
Sorry, forgot to say: I'm using a Mac!
OMG, I can't believe it!!! I found the solution: Removing the original stylesheets (manually with Firebug or with a greasemonkey script) of the page was the trick. I don't know, where the bug is (Firefox or Mac OS)... it seems, that the background-images of whatever are saved into the pdf, altough they are completely hidden via my stylesheet.
Thanks for your help!
Related
I am using Century Gothic font in my HTML and then converting it in to PDF. It works perfectly on my mac, but on my Slackware 14.1 server, when I convert the HTMl in to the PDF, the font is not rendered as smoothly as it should be.
I read several ways to include non-standard fonts in the HTML, as #font-face, or adding the entire font in the CSS file as an encoded font and both these methods worked for me in the HTML. The HTML is rendered perfectly in the browser, it's the PDF which is not getting a correct Century Gothic. Any help is highly appreciated.
Thank you
I did some research too and it seems that this is a known bug with qt-webkit.
See the issue documentation here:
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/2193
Sorry to not have better news for you. Maybe just try with a supported font that's close enough to what you like it to look?
I have a site - www.jcrocetta.com.
On this site I have 2 pdf files. One file has blurred data and the other is clear, both files were created with pdftk.
In order to blur out some personal data in the pdf I used Inkscape. But Inkscape only opens/edits one PDF page at a time. After I made my edits in Inkscape I saved the files as .pdf formatted files. At that point I had three separate pdf files, pages 1 through 3. I then used pdftk to concatenate the 3 files into one.
The final pdftk-produced files are on www.jcrocetta.com. Just click the public information button.
In Chrome viewing inline works fine.
Downloading the file from Firefox works fine too.
But viewing inline on Firefox it renders blank pages. How can I fix this?
Also, I know that pdf files not produced with pdftk will render correctly on both Chrome and Firefox.
Thanks for your help.
FireFox has a lovely new feature: It now uses the PDF.js library to render PDF files, instead of calling out to an Adobe Reader plugin, or forcing you to save the file to disk. Unfortunately, it seem that PDF.js isn't quite perfect yet. A quick search shows that other people have the same issue, but the only "solution" I've seen offered boils down to "file a bug report at https://github.com/mozilla/pdf.js/issues or https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=PDF+Viewer".
Also: Do the three individual PDF files render in FireFox, before you use pdftk to concatenate them?
I have a logo that shows up in Safari but in Chrome it appears as a broken link and simply does not show up at all in Firefox.
<img src="images/logo-01.png"/>
I have re-uploaded it many times and have even tried alternative paths and file names.
anyone know how i might be screwing this up?
I ran into this same problem. For me, it turns out the image was corrupt. If i tried to open the png file up in photoshop, i would get an error saying it could not parse the file.
For whatever reason, safari could display the corrupt file, but chrome could not. This is how i fixed my issue. I noticed "preview" on my macbook could open the file fine. If you are using windows, possibly try paint or gimp or some other program besides photoshop.
I downloaded the corrupt file onto my macbook, opened it with preview (open with > preview)
In the preview app, go to file > duplicate, which makes a copy of your image
Save that duplicated image
As a test, i tried opening that new copied image in photoshop and i was able to!
Upload new file to website. I was able to view the image in chrome now.
Hope that helps anyone who ran into the same problem.
It could be an issue with your file structure. Right now your links are using relative paths (e.g. href="index.html"). This is fine if the file you're referencing is in the same directory as the current page file. But if your current page is located elsewhere, like in a 'pages' directory or something, then you need to tell the links to start from the site root. That would look like href="/index.html" (note the slash). So for the image, you'd have:
<img src="/images/logo-01.png"/>
I am using fckEditor as text editor. When i upload images thru it the images were uploaded to app/webroot/fckeditor/images.
And when they're embedded it looks like
/fckfiles/SalmonSashimi.jpg
Until now it looks right.
But the image doesn't appear.
So when I browse the image directly, at here
http://www.in-culture.info/fckfiles/SalmonSashimi.jpg
instead of displaying the URL, Cake interrupts the image call and trying to render it in a layout. I often face this error when I point .html file for iframe scroller and .xml file for flash embedding. This is really embarrassing
You can see the page here
http://www.in-culture.info/events/view/42
That image should appear before the text - "More" dont appear for short text.
Thanks for you help.
Try to change the path where the images are saved. Instead of
/app/webroot/fckeditor/images
try to change to
/app/webroot/img/fckeditor/
I believe that it's possible.
It's resolved now.
It was not cake's fault.
I pointed incomplete absolute path at FckEditor so it didn't upload the files well.
However the uploader mistakenly passes the "OK" so the HTML tries to display it.
So cake tries to render something, as usual, when there is no physical file.
I spent about 10 hours to resolve this.
Now I don't hate cake as I did a few hours ago. (: :)
I'm trying to load an image from the Firefox cache as the title suggests. I'm running Ubuntu, so the location of my cache is /home/me/.mozilla/firefox/xxxxxx.default/Cache
However, in the Cache (and this is on Mac, too) the filenames are just ridiculous combinations of letters and numbers. Is there a way to pinpoint a certain file?
You should take a look at the source code of the CacheViewer Add-on.
Download the file instead of installing it (right click and save as) and then extract it (it's just a Zip file, even though it has a .xpi extension), then extract the cacheviewer.jar file inside the resulting chrome folder. Finally go into content and then cacheviewer to find the javascript and XUL files.
From my brief investigation, the useful routines are in the cacheviewer.js file, though if you were hoping there would be a simple javascript one liner for accessing cached items you're probably going to be disappointed. The XUL files (which are just XML) are helpful in working out which JS functions are called to perform particular tasks. I'm not too sure how all this maps into Greasemonkey, rather than the extension environment, but hopefully there's enough code to get you started.
Ummm, that really is an internal implementation detail. But I suggest looking at how about:cache?device=disk and about:cache-entry?client=HTTP&sb=1&key=https://stackoverflow.com/Content/img/wmd/blockquote.png are implemented.
Also, http://www.securityfocus.com/infocus/1832 gives details, too. Note that Firefox doesn't use a separate file for everything...
And of course, Firefox may change the format at any time.
Just give your img src= attribute the full URL. If the image happens to be cacheable (the server sends an appropriate Expires: or Cache-control: header, for example) and it's already in the cache, Firefox will not hit the network.
HTTP caching is supposed to be invisible. When you're generating content, you generally shouldn't worry about it.
You can point REDbot at a URL to see all sorts of delicious information about its cacheability.