Printing #40

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

Comments

Projects
None yet
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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Oct 15, 2012

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.

Owner

coolwanglu commented Oct 15, 2012

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

This comment has been minimized.

Show comment
Hide comment
@stanbellcom

stanbellcom Oct 15, 2012

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

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Oct 15, 2012

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.

Owner

coolwanglu commented Oct 15, 2012

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

This comment has been minimized.

Show comment
Hide comment
@stanbellcom

stanbellcom Oct 15, 2012

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?

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Oct 15, 2012

Owner

could you please send me an email (which can be found in the project home
page)?

On Mon, Oct 15, 2012 at 11:02 PM, stanbellcom notifications@github.comwrote:

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?


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-9448114.

Owner

coolwanglu commented Oct 15, 2012

could you please send me an email (which can be found in the project home
page)?

On Mon, Oct 15, 2012 at 11:02 PM, stanbellcom notifications@github.comwrote:

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?


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-9448114.

@deathlord87

This comment has been minimized.

Show comment
Hide comment
@deathlord87

deathlord87 Oct 17, 2012

@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 👍

@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 👍

@iapain

This comment has been minimized.

Show comment
Hide comment
@iapain

iapain Oct 19, 2012

Collaborator

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

Collaborator

iapain commented Oct 19, 2012

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

@coolwanglu

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Oct 19, 2012

Owner

Yes, it should be about CSS, here are the things I'll need to do.

To calculate (separatedly) the metrics for printing, like height/width and
font sizes
To tweak the css for several elements, hide the visual effects

These should not be hard, but I'm investigating why the fonts are not
working, they should be.

On Fri, Oct 19, 2012 at 3:35 PM, Deepak notifications@github.com wrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-9592081.

Owner

coolwanglu commented Oct 19, 2012

Yes, it should be about CSS, here are the things I'll need to do.

To calculate (separatedly) the metrics for printing, like height/width and
font sizes
To tweak the css for several elements, hide the visual effects

These should not be hard, but I'm investigating why the fonts are not
working, they should be.

On Fri, Oct 19, 2012 at 3:35 PM, Deepak notifications@github.com wrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-9592081.

@stanbellcom

This comment has been minimized.

Show comment
Hide comment
@stanbellcom

stanbellcom Oct 19, 2012

@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).

@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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Oct 19, 2012

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.

Owner

coolwanglu commented Oct 19, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@deathlord87

deathlord87 Oct 22, 2012

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Nov 9, 2012

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.

Owner

coolwanglu commented Nov 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Dec 11, 2012

Owner

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

Owner

coolwanglu commented Dec 11, 2012

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

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Jan 24, 2013

Contributor

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.

Contributor

jahewson commented Jan 24, 2013

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Jan 24, 2013

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.

Owner

coolwanglu commented Jan 24, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@purem

purem 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

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

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

Owner

coolwanglu commented Feb 4, 2013

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

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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

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

Contributor

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 😄

@coolwanglu

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

Great news. So it is worth a new try.

On Mon, Feb 4, 2013 at 9:01 PM, John Hewson notifications@github.comwrote:

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

I'm using Firefox 18, and web fonts now print correctly [image: 😄]


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13075745.

Owner

coolwanglu commented Feb 4, 2013

Great news. So it is worth a new try.

On Mon, Feb 4, 2013 at 9:01 PM, John Hewson notifications@github.comwrote:

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

I'm using Firefox 18, and web fonts now print correctly [image: 😄]


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13075745.

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

It must be about CSS.

So now here are the things to do

  • Set proper CSS for the UI
  • Set a separate CSS file for printing, basically to change units (px->pt)
  • Set proper page-breaks (CSS property page-break-before/after)
  • (possible?) Disable header/footer/margin for printing

I'll check them out later.

On Mon, Feb 4, 2013 at 9:13 PM, John Hewson notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076212.

Owner

coolwanglu commented Feb 4, 2013

It must be about CSS.

So now here are the things to do

  • Set proper CSS for the UI
  • Set a separate CSS file for printing, basically to change units (px->pt)
  • Set proper page-breaks (CSS property page-break-before/after)
  • (possible?) Disable header/footer/margin for printing

I'll check them out later.

On Mon, Feb 4, 2013 at 9:13 PM, John Hewson notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076212.

@purem

This comment has been minimized.

Show comment
Hide comment
@purem

purem Feb 4, 2013

I have been hacking around with the @font-face generation. I am creating a
branch where you can pass a comma delimited array of types rather than one
type. I then format them in a way which is cross browser. Maybe this will
help?

On 4 February 2013 13:20, Lu Wang notifications@github.com wrote:

It must be about CSS.

So now here are the things to do

  • Set proper CSS for the UI
  • Set a separate CSS file for printing, basically to change units (px->pt)
  • Set proper page-breaks (CSS property page-break-before/after)
  • (possible?) Disable header/footer/margin for printing

I'll check them out later.

On Mon, Feb 4, 2013 at 9:13 PM, John Hewson notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHub<
https://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076212>.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076468.

purem commented Feb 4, 2013

I have been hacking around with the @font-face generation. I am creating a
branch where you can pass a comma delimited array of types rather than one
type. I then format them in a way which is cross browser. Maybe this will
help?

On 4 February 2013 13:20, Lu Wang notifications@github.com wrote:

It must be about CSS.

So now here are the things to do

  • Set proper CSS for the UI
  • Set a separate CSS file for printing, basically to change units (px->pt)
  • Set proper page-breaks (CSS property page-break-before/after)
  • (possible?) Disable header/footer/margin for printing

I'll check them out later.

On Mon, Feb 4, 2013 at 9:13 PM, John Hewson notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHub<
https://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076212>.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076468.

@coolwanglu

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

The reason I chose TrueType as the default one, is that this format is
supported by all decent browser. Otherwise the generated HTML files cannot
be even correctly displayed on screen.
I guess that font format is not a problem right now.

On Mon, Feb 4, 2013 at 9:29 PM, purem notifications@github.com wrote:

I have been hacking around with the @font-face generation. I am creating a
branch where you can pass a comma delimited array of types rather than one
type. I then format them in a way which is cross browser. Maybe this will
help?

On 4 February 2013 13:20, Lu Wang notifications@github.com wrote:

It must be about CSS.

So now here are the things to do

  • Set proper CSS for the UI
  • Set a separate CSS file for printing, basically to change units
    (px->pt)
  • Set proper page-breaks (CSS property page-break-before/after)
  • (possible?) Disable header/footer/margin for printing

I'll check them out later.

On Mon, Feb 4, 2013 at 9:13 PM, John Hewson notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHub<
https://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076212>.


Reply to this email directly or view it on GitHub<
https://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076468>.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076752.

Owner

coolwanglu commented Feb 4, 2013

The reason I chose TrueType as the default one, is that this format is
supported by all decent browser. Otherwise the generated HTML files cannot
be even correctly displayed on screen.
I guess that font format is not a problem right now.

On Mon, Feb 4, 2013 at 9:29 PM, purem notifications@github.com wrote:

I have been hacking around with the @font-face generation. I am creating a
branch where you can pass a comma delimited array of types rather than one
type. I then format them in a way which is cross browser. Maybe this will
help?

On 4 February 2013 13:20, Lu Wang notifications@github.com wrote:

It must be about CSS.

So now here are the things to do

  • Set proper CSS for the UI
  • Set a separate CSS file for printing, basically to change units
    (px->pt)
  • Set proper page-breaks (CSS property page-break-before/after)
  • (possible?) Disable header/footer/margin for printing

I'll check them out later.

On Mon, Feb 4, 2013 at 9:13 PM, John Hewson notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHub<
https://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076212>.


Reply to this email directly or view it on GitHub<
https://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076468>.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13076752.

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

@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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

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.

On Tuesday, February 5, 2013, John Hewson wrote:

@purem https://github.com/purem font files are big, you don't really
want to be sering 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.

@coolwanglu https://github.com/coolwanglu maybe WOFF should be the
default font format nowadays?


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13085394.

Owner

coolwanglu 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.

On Tuesday, February 5, 2013, John Hewson wrote:

@purem https://github.com/purem font files are big, you don't really
want to be sering 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.

@coolwanglu https://github.com/coolwanglu maybe WOFF should be the
default font format nowadays?


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13085394.

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

maybe old IE... I will test again.
But what's wrong with ttf?

On Tuesday, February 5, 2013, John Hewson wrote:

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 also support
TrueType.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13085812.

Owner

coolwanglu commented Feb 4, 2013

maybe old IE... I will test again.
But what's wrong with ttf?

On Tuesday, February 5, 2013, John Hewson wrote:

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 also support
TrueType.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13085812.

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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".

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

So how can you do it in one rule?

On Tuesday, February 5, 2013, John Hewson wrote:

So now here are the things to do
...


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13086780.

Owner

coolwanglu commented Feb 4, 2013

So how can you do it in one rule?

On Tuesday, February 5, 2013, John Hewson wrote:

So now here are the things to do
...


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13086780.

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

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

On Tuesday, February 5, 2013, John Hewson wrote:

You can't. 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.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13089069.

Owner

coolwanglu commented Feb 4, 2013

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

On Tuesday, February 5, 2013, John Hewson wrote:

You can't. 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.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13089069.

@purem

This comment has been minimized.

Show comment
Hide comment
@purem

purem 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.

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

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

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

On Tuesday, February 5, 2013, John Hewson wrote:

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 http://www.w3.org/TR/css3-mediaqueries/ for print which overrides
your usual styles.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13090228.

Owner

coolwanglu commented Feb 4, 2013

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

On Tuesday, February 5, 2013, John Hewson wrote:

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 http://www.w3.org/TR/css3-mediaqueries/ for print which overrides
your usual styles.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13090228.

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@purem

purem Feb 4, 2013

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

purem commented Feb 4, 2013

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

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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...

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

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

An option for multiple fonts sounds good, but I think ttf is good enough
for default.

On Tuesday, February 5, 2013, purem wrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13090096.

Owner

coolwanglu commented Feb 4, 2013

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

An option for multiple fonts sounds good, but I think ttf is good enough
for default.

On Tuesday, February 5, 2013, purem wrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13090096.

@coolwanglu

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

I am not sure. fontforge does all the font jobs.

But I guess so.

On Tuesday, February 5, 2013, John Hewson wrote:

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 https://github.com/coolwanglu, does pdf2htmlEX do this? It
needs to if not...


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13090624.

Owner

coolwanglu commented Feb 4, 2013

I am not sure. fontforge does all the font jobs.

But I guess so.

On Tuesday, February 5, 2013, John Hewson wrote:

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 https://github.com/coolwanglu, does pdf2htmlEX do this? It
needs to if not...


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13090624.

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@purem

purem 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?

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

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

@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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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

@coolwanglu what exactly is the problem with that?

Contributor

jahewson commented Feb 4, 2013

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

@coolwanglu what exactly is the problem with that?

@coolwanglu

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 4, 2013

Owner

not problem, but things to do.

On Tuesday, February 5, 2013, John Hewson wrote:

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

@coolwanglu https://github.com/coolwanglu what exactly is the problem
with that?


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13093480.

Owner

coolwanglu commented Feb 4, 2013

not problem, but things to do.

On Tuesday, February 5, 2013, John Hewson wrote:

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

@coolwanglu https://github.com/coolwanglu what exactly is the problem
with that?


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13093480.

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

Yes, lots to do!

Contributor

jahewson commented Feb 4, 2013

Yes, lots to do!

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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...

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 4, 2013

Contributor

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

Contributor

jahewson commented Feb 4, 2013

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

@coolwanglu

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 5, 2013

Owner

I already mentioned page-break-before/after in the "things to do" list

About CSS, for screen, the default UI needs a fix-height container to
handle scrolling etc, let me see if ":visible" from jquery works. But
anyway separate media queries should work.

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

On Tue, Feb 5, 2013 at 3:59 AM, John Hewson notifications@github.comwrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13095945.

Owner

coolwanglu commented Feb 5, 2013

I already mentioned page-break-before/after in the "things to do" list

About CSS, for screen, the default UI needs a fix-height container to
handle scrolling etc, let me see if ":visible" from jquery works. But
anyway separate media queries should work.

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

On Tue, Feb 5, 2013 at 3:59 AM, John Hewson notifications@github.comwrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/coolwanglu/pdf2htmlEX/issues/40#issuecomment-13095945.

@jahewson

This comment has been minimized.

Show comment
Hide comment
@jahewson

jahewson Feb 5, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 5, 2013

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.

Owner

coolwanglu commented Feb 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 5, 2013

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...

Owner

coolwanglu commented Feb 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@coolwanglu

coolwanglu Feb 28, 2013

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. 😆

Owner

coolwanglu commented Feb 28, 2013

@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. 😆

@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