On Thu, 06 Feb 2014 11:56:48 -0600, "Steve Thackery"
Post by Steve ThackeryPost by Java JiveJust so. If anyone responsible for the mess that is IE walked through
my door just now, his/her life would hang by a thread.
That's strange.
It is, if you'd heard my cursing over the last 48 hours or so, you'd
wonder at my moderation.
Post by Steve ThackeryIE11 is widely regarded by computery-types as one of
the fastest, most standards-compliant, and most secure browsers you can
get, in stark contrast to earlier versions, which were amongst the
worst in all those respects. MS has really turned it around,
apparently. In truth it has almost nothing in common with the
"notorious" versions of IE from several versions ago.
Would these be the same 'computery-types' who design fixed width
instead of fluid design web-pages, thus forcing us all to scroll back
and forth with a horizontal scroll bar just to read a paragraph of
text? This may seem at first to be merely a point-scoring jibe back
to a former disagreement between us, but actually I'm trying to make
again a rather deeper and more subtle point that I made then and that
is relevant to both discussions ...
These 'computery-types' live and work in a particular 'culture', in
the socio-biological sense of the word. Group conformity tends to be
a very marked feature of such cultures. Thus you tend not to find
anybody raising a stink because they've discovered a failing in
something, if indeed the failing is ever discovered at all in a world
where everybody behaves and works in a similar fashion, and so never
does anything unusual enough to discover it. Technology used under
the modus operandi of and within the culture of the people who create
it will be well tested in that environment by those very people,
almost by definition. The problem is that without a proper testing
regime, the moment anybody from a different culture does anything
different with the technology, they are likely to find themselves on
relatively or even completely untested ground.
These days in IT (is that term itself is now outdated?), the emphasis
is very much on mobile devices, and 'traditional' IT values like
hardcopy are very much neglected by everyone involved in
web-technology - from the creators of mobile hardware, through the
creators of browsers, through the creators of content, down to many
end-users. However, hardcopy still makes sense in many situations ...
I've mentioned before the Open C Guitar Tuning Tutorial on my website.
No one is going to want to learn a new guitar tuning craning their
necks to see tiny chord diagrams on a mobile phone laid horizontally
on a desk, and which keeps turning off after a minute or so, and even
sitting at a PC with a reasonably sized monitor may not be convenient.
The obvious way to use such a tutorial is to print it out and place it
on a music stand, and its pages were designed with exactly that in
mind.
Similarly, though I'm aware that many people do it, I would prefer not
to juggle with an expensive device such as a mobile phone at the top
of a ladder, and have to get my glasses out just to read it - let's
think about that for a moment: I'm holding the phone in one hand,
with my second I get the glasses case from my pocket and hold it, with
my third I'm opening the case, taking out the glasses and putting them
on my nose, and with my fourth I'm holding on the ladder. At least
that's what might happen if I was prepared to wait long enough for
evolution to kick in. However, I prefer the quicker and surer approach
of printing out the results from my alignment calculators, and then I
can read them without glasses, and the worst that can happen is that
they blow away in the wind. Accordingly, the calculators' output has
again been designed to print on sheets of A4 or Letter.
I'm sure that you could think of other examples.
But how much testing of printing is done these days? Judging by the
way IE has always had problems printing maps, b*r all, at least as far
as IE and maps are concerned. For those who are really interested, by
way of example I've made up a zip of screen grabs of the print
previews of FF26, & IE11 with the setting File, Page Setup, Enable
Shrink-to-Fit disabled (the content is DESIGNED to fit, after all).
The zip also includes an old screen-grab of dish pointer's output in
IE6 from 2008 (I should say that ISTR that, when I last checked, the
printout from the site had been improved), which is relevant to a
point I make further on:
http://www.macfh.co.uk/Temp/IEPrint.zip (about 3.6MB)
The four pages from FF are pretty good - the headers and footers are
so near the page margins that I suspect most printers would not be
able to print them fully, but at least the content is entirely
correct. IE's problems begin even on p1 - such items as <abbr> tags
are not obeying "background-color:inherit;" from the site stylesheet;
no matter, I shouldn't have to do it, but I can get around that by
specifically giving them the style ...
@media print{ abbr {background-color:#FFFFFF; } }
... The real problems begin on p2, where despite the
"page-break-after:always;" setting on that page, the OS map from the
next page has 'leaked' backwards across the supposed page break into
the space beneath the Google Map, page 3 is also a mess at the top and
the bottom, and vital information has similarly been lost by the OS
map leaking forwards over the profile diagram on page 4. Press
Compatibility View and set up the calculator again, and all these
problems just go away, but then you've got the clunkiness and other
problems of legacy IE.
Post by Steve ThackeryWhich makes me wonder: is the page itself fully compliant? If not, it
may be that the less "fussy" browsers are happy to print it, whereas
IE11 isn't.
Both pages are fully compliant, in the sense that without the PHP
compression envelope, the first and last lines, they parse/pass a
compliance test here:
http://validator.w3.org
However, I can't know if output of the mapping scripts themselves are
compliant - they produce and style dynamically various <divs>, load
tile images, etc. Both Google and OpenLayers produce some CSS errors
in the debugging console of various browsers - most notably, OL
using 'filter' to set opacity in legacy IE produces many CSS warnings
in non-IE browsers. However, if these were going to cause a problem,
one would expect it to happen in the non-IE browsers, not the various
versions of IE!
Post by Steve ThackeryOr maybe I'm wrong and it really is a problem with IE - I don't recall
any reviews addressing how well it prints things, so of course it could
be that.
IE has a very long history of trouble printing maps, as evidenced by
the output from dish pointer in 2008 that is included in the zip. It's
not been alone on this journey - legacy Opera never managed it
either; IIRC FF2 was pretty bad, and FF3 had an ugly vector graphics
glitch that was only fixed around 3.5, but all versions I've tested
since have been pretty good; early versions of Webkit browsers such as
Chrome and Safari had some glitches, but they too seem to do an
adequate job now. However, IE has NEVER got it right.
The most fundamental problem seems to be that it doesn't make any
attempt to ensure that the entire map will actually fit on what is
left of the page, and move it entirely to the next page if it won't.
ISTR that actually it makes the same mistake with an image as well,
attempting to cut it in two and print the two disembodied bits on
successive pages!
Given this failing, and, perhaps, a couple more, if you consider for a
moment the question: "In HTML terms, what is a map?" you can see how
it largely explains the printout faults that I've demonstrated. In
HTML terms, a map is fundamentally layers of <img> tags, which are
given different z-orders to produce the composite whole that, to our
eyes, seems like a single image.
On the bottom layer, we have a rectangular grid of map tiles, each of
which is an <img>. Note that the visible edge of the map viewport may
not necessarily coincide with the edge of a tile, indeed it probably
won't, so there has to be a mechanism whereby areas of each tile that
are outside the map viewport boundary are invisible. In the printouts
we can see that outer tile edges that should be invisible are actually
being printed by IE, but curiously, this only seems to be a problem at
the top and bottom of the page containing the OS map, for some reason,
the tiles at the side edges don't exhibit the problem. Thus the tiles
at the top of the map 'leak' backwards onto the bottom of the previous
page and the those at the bottom leak forwards onto the top of the
next.
Above this bottom layer we may have some vector graphics such as
markers which can be considered as attached to particular map tiles
and so move around with them as the map is panned. These markers must
have 'transparent' backgrounds so that the underlying tiles are
visible right up to the edge of the marker shape even though it's not
rectangular, and we can see that IE is at least getting that right
now, but I can remember seeing black rectangles around the markers in
browser printouts of old.
Above this we have the map controls such as the map type buttons in
Google, the layer switcher in OpenLayers, and the pan and zoom
controls and scales of both. These are fixed relative to the
viewport, and therefore must remain stationary as the map is panned
and zoomed. These may be given a semi-opaque background in order to
make them more visible against the differing backgrounds of map tiles
as the whole is panned and zoomed about, and the browser printout
should reproduce that faithfully. Also, many of these controls, for
example the pan and zoom controls, only have meaning on an interactive
map, and should not be printed, while others such as the scales should
be printed. This is something that the mapping scripts rather than
the browser should take care of, but I mention it for completeness and
because OpenLayers neglects this point, and I have had to edit their
stylesheet and some of their code accordingly.
Which raises the question, have *I* done something to produce the
glitches I've demonstrated? No, but it's taken most of the last 24
hours to prove it conclusively. Here are three demos that do so:
1) A version of the calculator that doesn't calculate. Any scripting
not required to produce a fixed typical sample of output has been
removed, and the original OpenLayers script is used, although map
customisations remain:
http://localhost/Local/JavaJive/AudioVisualTV/TerrestrialTV/TerrestrialCalculatorTest1.html
2) As above, but with the form removed, which then allows all my
site's styling also to be removed - the only remaining styling is
that required to set the map sizes and (attempt to) force a page-break
between each remaining page. Again map customisations remain:
http://localhost/Local/JavaJive/AudioVisualTV/TerrestrialTV/TerrestrialCalculatorTest2.html
3) As above, but with the map customisations and vector graphics
removed, and the Ordnance Survey map loaded by their OpenSpace
scripting, which is based on OpenLayers v12. My own code input is now
at the absolute minimum required to actually draw the maps:
http://localhost/Local/JavaJive/AudioVisualTV/TerrestrialTV/TerrestrialCalculatorTest3.html
All these demos still show the problem displayed in the demo outputs
from the zip. It seems that, although IE8+ now has no trouble with
Google Maps of the type demonstrated in the IE6 dish pointer example
from 2008, it can't now display OpenLayers maps! The problem must lie
with IE8+, because OL maps print fine in all the other browsers I've
been able to test, including IE7-.
To revert to the basic problem of how unintelligently IE prints
images, up to and including IE7, programmatically* one could do
something about this problem of it splitting them across page
boundaries, because IE7- used to obey some of the @media print styles.
Unfortunately, Microshaft subsequently dropped support for @media
print , so the problems that have actually always been there have now
become unsolvable unless one uses the Compatibility View button, a
Meta-tag, or a Response Header - produced by, say, PHP sensing the
requesting browser - to force a return to legacy IE7, but, as I
indicated previously, these last two options no longer work in IE11+,
and where they did work in the intermediate versions they sent the
user back to the clunkiness of legacy IE, though for myself, I don't
mind clunkiness as long as it actually does work, and, as previous
versions of the calculators showed, it did.
* For the really, really interested, I explain here how. The one
@media print style that IE seemed to support consistently up to and
including IE7 was "page-break-after" which can take the values
"avoid", "auto" (the default), and "always" with a possible rider of
"!important". It would have been much more convenient if IE had
actually supported instead "page-break-inside:avoid!important;", or
even just "page-break-before", but it didn't, only "page-break-after".
Thus, as a trivial example, my site's stylesheet includes the
following to prevent orphaned section titles at the bottom of printed
pages:
@media print
{
h1, h2, h3, h4, h5, h6
{ page-break-after:avoid!important; }
}
However, even using only "page-break-after", I was able to devise the
following that worked not only in legacy IE, but also in all the other
browsers that I tested.
The printable output is divided into pages, each of which occupies a
<div>, as follows:
Page 1: The page titles and form, between which are various expandable
Help sections which are visible on screen but don't print.
Page 2: The Google map, sized to fit on either A4 or Letter.
Page 3: The UK OS OpenLayers map, ditto.
Terrestrial Calculator only:
Page 4: The path profile diagram and key.
Any page that needs to print is given a style class "printpage" - the
first rule is the one that matters, the second merely centres the maps
between the left and right margins of the page:
@media print
{
.printpage
{ width:100%; height:99%; page-break-inside:avoid!important; }
.printpage .OLMap
{ margin-left:auto!important; margin-right:auto!important; }
}
Any page that shouldn't print - because, say, the map button has not
been clicked, so there is no map, so we don't want to waste a sheet of
paper - is given a style "invis" - note that this means it is both
invisible on the screen and also doesn't print, and in neither case
does it consume space:
.invis
{ display:none; margin:0; padding:0; line-height:0; }
Page 1 always has the class "printpage" as above, and the sections
within it that do not print have the style "noprint"
@media print
{
.noprint
{ display:none; margin:0; padding:0; line-height:0; }
}
The remaining pages start out as "invis". When a map or profile
button is clicked, the coresponding page div is programmatically given
the class "printpage", and then a javascript function loops through
the second and subsequent pages seeing which are currently set to
print, and whenever one is found, the PREVIOUS page THAT IS ALSO
PRINTING is programmatically given the style
"page-break-after:always"; any other pages are set to
"page-break-after:auto" which is the relatively innocuous default.
When a button is <Ctrl-Click>ed to remove a map or profile, the page
div is once more given the style "invis" and the same routine run
again to reset where necessary "page-break-after" back to default.
Here is that function definition for the terrestrial calc (beware line
wrap):
// Set print styles
function setPrintCSS()
{
var lastPage = 4, noprint = new RegExp( "\\b(?:invis|noprint)\\b" ),
p1, p2, elem, found;
for( p1 = 1; p1 <= lastPage; p1++ )
{
for( p2 = p1 + 1, found = false; (p2 <= lastPage) && !found; p2++
)
{
noprint.lastIndex = 0;
found = !noprint.test( document.getElementById("Page" +
p2).className );
}
elem = document.getElementById( "Page" + p1 );
elem.style.pageBreakAfter = noprint.test( elem.className ) ||
!found ? "auto" : "always";
}
}
In this way, IE's, in particular, and other browsers', in general,
failures to provide even something as relatively obvious, basic, and
simple as obtaining decent printout could be overcome.
However, such widespread and basic failings cause web developers to
have to pollute their code with a complex marathon of fixes, tests,
trials, etc, to supply the deficits. It gets so that we actually
spend more of our time trying to fix these absurd glitches than we do
programming the big picture that is actually more interesting to do.
In effect, we become unpaid dogsbodies of the browsers' development
teams.
It's very, very, very frustrating.
--
=========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html