Printing pages with different scale changes text to image

[Kurtb]

I have ran into something that has confused me for years but now I can force a change to repeat the result (a testers dream). Unfortunately I was never really a software tester so I do not really know all the terms and what is exactly needed here.

I was making pdfs of the following page: http://events.gotsport.com/events/sched ... rls&Age=10
When I reviewed the pdf I could highlight the first page's text but not the second page. I have never seen both 'ways' in a single file before. Usually the text is either selectable or it appears to be an image (I gather the proper term is raster or rasterized) and, as far as I have noticed so far, is consistent on all pages (if all pages actually print). I have assumed it was something the website set so I did not look into it. Now my curiosity forced me to play with the print preview's 'scale'. Initially the scaling was set to 'shrink to fit'. When I chose 80% both pages now have text that is selectable (awhile back I found print selection can occasionally do the same thing). The file size also went from 278KB to 25KB. I was not adventurous to try other values.

To eliminate the pointed statement that it is my pdf generation (PDF-XChange Printer 2012) I tried the following other printers:
Microsoft XPS Document Writer: each file shows the same results. Scale set to 'Shrink to fit' has page 1 as text and page 2 as an image. A scale setting of '80%' has text on both pages.
HP LaserJet 5200: as I expected, it is too hard to tell

I am sorry if there is an existing topic but I could not find anything exact. I found the following but I did not feel it is best to add to either of them:
http://forums.mozillazine.org/viewtopic ... &t=2213759
http://forums.mozillazine.org/viewtopic ... &t=2807027

This sounds the same but it is pretty old:
https://bugzilla.mozilla.org/show_bug.cgi?id=329886

I do not know what information to post other than this:
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46
Build identifier: 20161213183751
Screen Resolution: 1920 x 1200
Page size: 8.5" x 11"

I have the files if that would help anybody understand what I am seeing. I am hoping it can be reproduced by somebody/anybody else as I will not be able to do much for a good month. I did debate about submitting a ticket at Bugzilla@Mozilla but I felt this is the best place to start.

I find it interesting, when I printed this topic as a pdf before I submitted it, the preview text is selectable but the editable area is an image.

[TPR75]

I was making pdfs of the following page: http://events.gotsport.com/events/sched ... rls&Age=10
When I reviewed the pdf I could highlight the first page's text but not the second page. I have never seen both 'ways' in a single file before. Usually the text is either selectable or it appears to be an image[...]

I can confirm this - first page is text and second is image. It must be something with that page not SeaMonkey or PDF printer.

If you want printable version of tables (text only on all pages of PDF) then use website's function "Print Schedule"/"Print Standings".

If you want entire website as PDF and you know HTML/CSS/JS then you can save page "as HTML" and edit file to remove such "feature". Don't ask me how.

[Kurtb]

TPR75 wrote:
I can confirm this - first page is text and second is image. It must be something with that page not SeaMonkey or PDF printer.

Did you see a change with different scaling? I have seen this many times before on the same websites but I never made the connection that it is related to scaling (which I have to use all the time as 'shrink to fit' is not reliable enough to scale properly). At the moment, I cannot see how the choice of text or image is set by the webpage if it can be changed with a setting related to SeaMonkey's printer. But it might explain why the problem comes and goes as the 'shrink to fit' has to change the scaling when determining how much to adjust.

[TPR75]

TPR75 wrote:
I can confirm this - first page is text and second is image. It must be something with that page not SeaMonkey or PDF printer.

Did you see a change with different scaling? I have seen this many times before on the same websites but I never made the connection that it is related to scaling (which I have to use all the time as 'shrink to fit' is not reliable enough to scale properly). At the moment, I cannot see how the choice of text or image is set by the webpage if it can be changed with a setting related to SeaMonkey's printer. But it might explain why the problem comes and goes as the 'shrink to fit' has to change the scaling when determining how much to adjust.

IMHO it's about website design.

When I print page to PDF with "Shrink to fit" (my default setting) then first page is not "all text" (which can be selected) but it's image too - right border/margin is image (observer how your mouse cursor is changing from "text selection" to "image marking").

When I print page to PDF with 100 percent (not all text is visible) or with 90 percent (all text is visible but right border/margin image is cut off) then I can select text on all PDF's pages. There are left some images but they're small and not for all hight of (first) page (mentioned border/margin).

Hmm... If there is any bug in SeaMonkey then it can "hide" with "print page setup". Open webpage with Print Preview and make sure that "Print Background (color & images)" option under "Page setup" button is enabled. Then you can see that first page only has background image (football/soccer field) and second one brown border only.

Firefox 50.x is affected as well because it behave the same. But not Internet Explorer 11 - it can preview and print webpage with background images and text on all pages is still selectable.

OK, it's a bug...

[TPR75]

... or it can't be problem with website design. Heh

I was really curious about this problem so I saved this webpage to new folder (as "complete site" plus extra background image) and I was trying to edit HTML file.

First I messed a little with background setting but it was false path. Correct one is "box-shadow":
https://developer.mozilla.org/en-US/doc ... box-shadow

Looks like adding just one word "inset" to this part:

Code: Select all

.ShadowBox {
	box-shadow: inset 10px 10px 5px rgba(0,0,0,0.5);
}

... allows to print as PDF with all pages selectable text.


To print (within SeaMonkey) background image on all PDF pages I changed "background-repeat" function:
https://developer.mozilla.org/en-US/doc ... und-repeat
... from "no-repeat" to "repeat".

Code: Select all

html {
	background-color:#bba16b;
	height: 100%;
	background-image: url('got_background_2016.jpg');
	background-repeat: repeat;
	background-attachment:fixed;
	background-size:cover;
}

There always were "problems" when creating websites to make them work under different browsers. AFAIK Microsoft made IE "a little bit different" and it handle not W3C standard but its own designed by Microsoft. At least webmaster says so...

EDIT: I'm not webmaster but it looks like "box-shadow" changes I made are wrong because it just removed shadow. The same result is when I delete that part of code.

[TPR75]

It's not a bug. It's a feature!

Bug was when Mozilla didn't print "box-shadow" elements:
http://forums.mozillazine.org/viewtopic ... #p13443035
https://bugzilla.mozilla.org/show_bug.cgi?id=989885

Now "feature" is box-shadows are printed as images:
https://support.mozilla.org/t5/Firefox/ ... d-p/989006

BTW I'm not using hardware acceleration in SeaMonkey.