Skip to content

Printing #40

Closed
stanbellcom opened this Issue Oct 15, 2012 · 54 comments

6 participants

@stanbellcom

HTML pages produced by pdf2htmlEX cannot be printed correctly (retaining the formats or correct paging)

This pages lists the reasons and difficulties.

This issue is left for discussing about possible solutions to it. Please read the wiki page above before leaving messages.

@coolwanglu
Owner

It's an old known issue, and has been in the TODO list for quite well.
Currently printing is not of high priority, as you can also provide the original PDF for printing, e.g. Wikipedia.

@stanbellcom

that is right,
however not quite applicable in my situation - I have integrated the output received from pdf2htmlEX with one of the HTML annotator, and by printing would like to get the rendered html + the created annotations.

can you please give some approximate date on when the printing feature will be available, if ever?

Thanks

@coolwanglu
Owner

Hmm, now I'm working on improving the background images, and there are quite a number of things to do after that. No guarantee on the speed, as I'm doing it in my spare time.

You may consider filing a commision if you want it be done soon.

@stanbellcom

that might be a possibility,

now that you know the issue, you could perhaps tell me what would be an estimate price to speed up this feature appearance?

@coolwanglu
Owner
@deathlord87

@stanstanbellcom
for annotating you could use ghostscript and add annotations on your pdf. By this your pdf's are modified and not the html. Annotations view for pdf2htmlEX is already requested and is being worked on :+1:

@iapain
Collaborator
iapain commented Oct 19, 2012

Isn't adding css to "print" would solve this?

@coolwanglu
Owner
@stanbellcom

@deathlord87
thanks for information, i'll look into it.
However it does not seem right for my application from the first sight - i'm having multiple users on a website, so that will mean that i'll need to have a copy of pdf for each single user.
With HTML annotation it's just easier - I serve the same HTML, and then add the notes onto it.
By the way, i'm using great tool: annotateit

but you're certainly right, this will help me solve the printing problem (if ghostscript can print with notes).

@coolwanglu
Owner

@stanbellcom I guess you can store only the original PDF, and generate an temporary annotated PDF when a user request for printing. But probably would make your system more complicated.

@deathlord87

@stanbellcom

ghostscript only takes in input as text files for annotations text and the the location/rect for annotation. You can create individual text files for each user accessing your app. (tryout HTML5 LocalStorage). When the user clicks download pdf then the GhostScript can be executed with the text to annotate his/her own pdfs.

@coolwanglu
Owner

According to my research on this, there are two major issues prevent it to be done

  • Firefox & Chrome do not print the pages with fonts introduced by @font-face
  • Paging cannot be controlled - the latest CSS standard is not supported by browsers right now, SVG might work for this.

So I guess this has to be done for quite a while.

If any one find a solution for this, please kindly tell me.

@coolwanglu
Owner

I have created a Wiki page for this issues and updated the issue description.

@jahewson

Paging cannot be controlled - the latest CSS standard is not supported by browsers right now, SVG might work for this.

SVG won't work for paging.

Most browsers support SVG 1.1, which does not include multiple pages. Multiple pages are part of SVG 1.2 Full, however SVG 1.2 Full was abandoned, and replaced by SVG 1.2 Tiny which some browsers support, but it does not include multiple pages.

The next version of SVG will be SVG 2.0, at some point in the distant future.

@coolwanglu
Owner

@jahewson
Thanks for the info.

So before this can be solved with some future version of CSS or SVG, providing the original PDF is the best solution.

@purem
purem commented Feb 3, 2013

This has a workaround for Firefox and Chrome not printing @font-face fonts:
https://getsatisfaction.com/fontdeck/topics/_font_face_embedded_fonts_do_not_show_up_in_a_print_preview

I'm not sure if its the exact issue but I thought I'd post it anyway on the off chance it may help

@coolwanglu
Owner

@purem, thanks for the info, but as also mentioned in that link, Firefox currenlty does not support this.

@jahewson
jahewson commented Feb 4, 2013

That Firefox bug has "Status: RESOLVED FIXED" since October 2012.

I'm using Firefox 18, and web fonts now print correctly :smile:

@coolwanglu
Owner
@jahewson
jahewson commented Feb 4, 2013

Printing pdf2htmlEX output in Chrome (23) is broken for me - I always get a single blank page. However, Chrome can print webfonts, because http://www.google.com/webfonts/specimen/Kavoon prints fine.

@coolwanglu
Owner
@purem
purem commented Feb 4, 2013
@coolwanglu
Owner
@jahewson
jahewson commented Feb 4, 2013

@purem font files are big, you don't really want to be serving up multiple formats if you can avoid it - especially as pdf2htmlEX embed the fonts as base64 data URIs.

TrueType works cross-browser everywhere except oldIE, which isn't supported by pdf2htmlEX. FontForge can't generate EOT files anyway. WOFF is now a viable option too, it's essentially a gzipped ttf file.

@coolwanglu maybe WOFF should be the default font format?

@coolwanglu
Owner
@jahewson
jahewson commented Feb 4, 2013

I remember that WOFF did not works for all...

Embedding is optional, so it's ok if you generate multiple files, and load
one of them according to the browser.

There's no point - all browsers that currently support WOFF already support TrueType.

@coolwanglu
Owner
@jahewson
jahewson commented Feb 4, 2013

So now here are the things to do
...

  • Set a separate CSS file for printing, basically to change units (px->pt)

No need, a CSS pixel is a 1/96".

@jahewson
jahewson commented Feb 4, 2013

But what's wrong with ttf?

Nothing really. WOFF files are compressed OTF files, so there's a size advantage. WOFF is supported almost everywhere worth bothering with now.

EDIT: turns out WOFF is not supported on Android.

@coolwanglu
Owner
@jahewson
jahewson commented Feb 4, 2013

TrueType is a good default, keep it as it is. Serving up gzipped TrueType with content-encoding: gzip is going to work everywhere except oldIE.

@coolwanglu
Owner
@purem
purem commented Feb 4, 2013

Lets look at this statistically

Total percent of users using a browser with
some support for @font-face: 93.09%
support for WOFF 76.61% (17% of users with some support excluded)
support for TTF 66.47% full, 16.03% partial -> 82.5% total (11% of users with some support excluded totally, 27% with support))

Summary stats
Best for IE -> EOT
Best for firefox -> TTF/OTF
Best for Chrome -> SVG/TTF/OTF
Best for Safari -> TTF/OTF
Best for Opera -> SVG
Best for iOS Safari -> SVG
Best for android -> TTF
Best for blackberry -> TTF/OTF / SVG
Best for opera mobile -> TTF/OTF/SVG
Best for chrome for android -> TTF/OTF/SVG
Best for firefox -> TTF/OTF/WOFF

Comments
To support anything before IE 9 you need to use EOT. IE only has partial support of TTF with @font-face.
To support old versions of iOS safari and opera you need SVG
TTF/OTF seems to trump WOFF in terms of compatability in all respects however the smaller file size of WOFF is obviously prefered.

Stats from:
http://caniuse.com/fontface
http://caniuse.com/woff
http://caniuse.com/ttf
http://caniuse.com/svg-fonts
http://caniuse.com/eot

To remedy this we can write fonts in all formats and then either:

A.) Use multiple font-face formats in the declaration. Font squirrel http://www.fontsquirrel.com/fontface/generator recommends the following as its "optimal" layout, "Recommended settings for performance and speed.". Its recommended by Paul Irish who knows his stuff and has done a long blog post on the ins and outs of @font-face declarations http://paulirish.com/2009/bulletproof-font-face-implementation-syntax/

@font-face {
font-family: 'pragmataproregular';
src: url('pragmatapro-webfont.eot');
src: url('pragmatapro-webfont.eot?#iefix') format('embedded-opentype'),
url('pragmatapro-webfont.woff') format('woff'),
url('pragmatapro-webfont.ttf') format('truetype'),
url('pragmatapro-webfont.svg#pragmataproregular') format('svg');
font-weight: normal;
font-style: normal;

}

Quick Explaination
The first declaration is for IE9 / IE10 as EOT is the prefered font (IEs format so supposdely it does a good job at it).
The second for IE8 and below. It will take the last src: statement as the one to use. IE8 and below have a bug in their parsers which results in 404s when more than one font is included in a src declaration. The ?#iefix tricks it into thinking everything after the ? is a query string and so it skips the other font formats.
http://stackoverflow.com/questions/8050640/how-does-iefix-solve-web-fonts-loading-in-ie6-ie8
The woff, ttf and svg fonts are read by the rest of the browsers if they can read them (see above for importance of all types if maximising compatability).
All browsers should only load one font so bandwidth really isn't an issue.

B.)
If they do, we could take the aproach that scribd takes and detect browsers before injecting a css file containing the fonts in the most relevant format. This would require writing a separate css file for each font type which contains all required fonts.

Neither are too hard to implement and will result in increased support. I propose that we make A. the default as this version doesn't require JS.

@jahewson
jahewson commented Feb 4, 2013

I meant the px and pt thing, I will have to create two sets of rules, for different media.

Ha ok. To get different rules for different media you need a CSS media query for print which overrides your usual styles. This is similar to the WebKit stroked text hack I used.

@coolwanglu
Owner
@jahewson
jahewson commented Feb 4, 2013

Best for iOS Safari -> SVG

@purem, that's very out of date. TTF has been supported since iOS 4.2, and WOFF since iOS 5.0.

@purem
purem commented Feb 4, 2013

SVG has best compatibility, its good to have it there just in case. Its minimal effort anyway.

@jahewson
jahewson commented Feb 4, 2013

IE only has partial support of TTF with @font-face.

Not really. Just turn off the font's "installable" flag in the TTF header.

@coolwanglu, does pdf2htmlEX do this? It needs to if not...

@coolwanglu
Owner
@coolwanglu
Owner
@jahewson
jahewson commented Feb 4, 2013

SVG has best compatibility, its good to have it there just in case. Its minimal effort anyway.

@purem - no, they're not supported by Firefox or IE. That's hardly "best compatibility". They don't contain hints so look like rubbish on Windows. A few years ago they were the only way to get web fonts on mobile, but not anymore.

@jahewson
jahewson commented Feb 4, 2013

Not sure if this will fix for IE <9, due to the html 5 tags used.

IE <9 only supports EOT fonts, which FontForge can't produce.

@purem
purem commented Feb 4, 2013

I was responding to your post. SVG has best computability for iOS. It doesn't matter that SVG isn't supported in Firefox and IE as they won't be used there!

Supporting more browsers will not be that much work and is a good thing. I'm implementing it now. There aren't any downsides. Whats the problem?

@jahewson
jahewson commented Feb 4, 2013

@purem, ok that's more like it, though the original post said "best", not "best compatibility". From a compatibility point of view it's a waste of time serving SVG fonts to iOS < 4.2 users, because that's only the first generation iPod Touch and iPhone. You're talking <1% of iPhone users, stuck on 5 year old technology.

Supporting more browsers will not be that much work and is a good thing.

It's a huge amount of work to actually test on these browsers, and you need to use an ancient iPhone which hasn't been updated to iOS 4.2. That's the wasted time, not the time it takes to code it. I guess you could just output the SVG font, stick it in the @font-face and hope for the best, but you have no idea if it actually works or not. Does the html and CSS for pdf2htmlEX content even render on iOS < 4.2 anyway, given that it's HTML5? Fonts are only one aspect of browser support.

@jahewson
jahewson commented Feb 4, 2013

That is what I meant, they are still two rules.

@coolwanglu what exactly is the problem with that?

@coolwanglu
Owner
@jahewson
jahewson commented Feb 4, 2013

Yes, lots to do!

@jahewson
jahewson commented Feb 4, 2013

Ok I found out why printing is broken in Chrome, it ignores absolute content when deciding the page size. There's a simple fix:

1. delete the following CSS attributes from #pdf-main:

position: absolute;
top: 0; 
left: 0;
bottom: 0;
right: 0;

2. add the declaration:

body {
   margin: 0;
}

Now printing in Chrome will work. It still needs some improvement though...

@jahewson
jahewson commented Feb 4, 2013

Looks like CSS has page-breaks http://davidwalsh.name/css-page-breaks

@coolwanglu
Owner
@jahewson
jahewson commented Feb 5, 2013

Does body {margin:0} remove the page margin when printing ?

No, but this might:

@page {
    margin: 0;
}

Ultimately the print margins are decided by the browser, OS, and print driver.

@coolwanglu
Owner

I've put into some CSS.

Now if you use the argument --zoom 1.333, the page should be able to be printed in Chrome. Looks good to me.

1.333 ~= 96/72, Default DPI is 72 in poppler (or in PDF ?) and 1pt=96 dots.

But there are still problems on Firefox. Only the first page prints.

If I remove the page-break-after/inside rules from CSS, All pages will print, but there's no page break.

Any ideas?

BTW, I'll be on travel for the next 24~48 hours, so please expect late replies.

@coolwanglu
Owner

Found a fix for Firefox. All pages show now.
It was a bug of Firefox that has been marked as fixed (in 2010?) but still reproduable...
https://bugzilla.mozilla.org/show_bug.cgi?id=129941

Users should manually enable printing background images/colors, disable headers/footers though the menus in Firefox.

There is a problem on Firefox is that when scale != 100%, the first 2 pages will collapse...

@coolwanglu
Owner

@stanbellcom

This feature is now roughly done, and marked as experimentally supported.

There are still a few problems though.

  • For browsers other than Chrome, you may need to manually enable printing background images/color
  • You need to manually disable header/footer for print (Any CSS solution ?)
  • May require a (quite) recent version of browsers

I've not tested with many pdf files, so please expect bugs.
But finally this issue may be closed. :laughing:

@coolwanglu coolwanglu closed this Feb 28, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.