Possibly at risk of boring some people rigid, I've decided I really can't
let this stand uncommented. I don't suppose DavidF will learn much from it
though, but we can live in hope.
In spite of the fact that the different versions of Publisher do not
produce 'standards compliant' html code, the truth is that you can indeed
produce cross browser compatible webs, just as you have in your own Pub
2002 website. The key is to know how to use the programs correctly.
Usually it is a relatively simple matter of tweaking the formatting, the
layout or the design a bit, but once you get a Pub web to work well in IE
and FireFox then it will also work well in all the other major browsers.
I've commented on this elsewhere so won't repeat myself.
The need to tweak the pages a bit is no different than any other program
you might choose to build your site with. Even Expression Web, MSFT's new
'standards compliant' web editor requires tweaking, except in that case you
have to tweak the actual code.
This is just plain wrong and reveals a lack of understanding of how other
methods work. Publisher generates html code for you as a part of its output
process, and gives no opportunity or facility to adjust or correct it other
than editing the code itself afterwards, which in the main is almost
impossible because it largely consists of poorly or undocumented proprietary
VML code. Expression Web is more of a coding aid - you effectively have to
write the code yourself. You can easily write non-standards compliant code
with it if you wish or don't understand what you are doing, but it makes it
much easier to get it right.
As stated elsewhere, the workaround for centering Publisher web pages
might not be 'proper' 'standards compliant' coding, but it does indeed
work,
It's not just that the suggested hacks aren't standards compliant - they're
just plain *wrong*. Admittedly they appear to work, so it's obviously not
immediately apparent why they shouldn't be used. Look upon it as a bad
misspelling of a written word - to successfully get the message across
relies upon the 'intelligence' and goodwill of the reader but it may be
misunderstood sometimes and you won't pass if you do it in an English exam.
I have detailed an improved technically correct method of achieving the same
result elsewhere, so it really shouldn't be an issue. Inexplicably DavidF
seems to have taken this as a personal insult.
It is just another example of where the need for standards compliant
coding is not required.
This just beggars belief. Nearly all the problems respondents have with
Publisher web pages are because the code Publisher generates isn't standards
compliant. DavidF's attitude is completely at odds with the rest of the
world here. The whole point of the changes in IE8 and the forthcoming
patches for Publisher are to move towards standards compliance and greater
interoperability for everything. There are lots of resources on the web
explaining why the current mess has arisen and why it needs to be fixed.
Here's just one:
http://www.evolt.org/article/Why_standards_compliant_HTML_matters/17/60446/index.html
Contrary to what you have been told, not all versions of Publisher will
"always resample" pictures when you produce your html pages.
I have little experience beyond an initial evaluation of Publisher versions
2002 and 2003 - these programs were found to be so poorly designed and
functionally deficient that we couldn't use them so I cannot really comment
on them with any authority. Publisher 2007 offers some advantages over 2000,
but it's still not to be recommended for making web pages.
2000 and 2007 certainly automatically resample images when you place them in
a page saved for the web. Your pages could not work in any useful manner if
they didn't. I should point out that it is possible for a web page to
contain a reference to an inappropriately large image though - browsers can
and do resample and resize images themselves based on information in size
tags which reference the image. That would have the effect of making your
pages inordinately slow to download and display. If Publisher relied on that
operation in versions 2002 and/or 2003 then it must have been a bug. Even
Microsoft couldn't deliberately design code that bad, but how it might have
got through their testing procedures is a mystery.
Pub 2000 did
automatically resample and produce a resized image at 96 dpi when you
produced your web pages.
This 96dpi thing... I don't know what David's on about here, it just doesn't
make sense. It is also mentioned in the Publisher documentation - it doesn't
make sense there either so at least he's consistent. What they probably mean
is in reference to the print mode of Publisher, where there is a physical
page size, and by implication a picture placed upon a page has a certain
size, and can therefore have a dpi value related to the number of pixels in
the image. I am risking venturing into complicated territory here, but a
picture alone cannot have a dpi value - it just has a number of pixels. The
dpi value becomes relevant when the picture is printed - ideally the dpi
should match the dpi value of the printer fairly closely for best results.
For correctness I should also point out that dpi (dots per inch) is not
necessarily the same as pixels per inch - although the terms are often used
interchangeably - and in the print world, definitely isn't. Pixels can have
a variable colour or grey value - dots are a single colour. In printing,
pixels are translated into clusters of dots which are used to make up
variable ranges of colour or grey. I digress.
Going back to web pages - computer screens have a fixed number of pixels
which make up the display. The size of a picture appearing on screen
therefore is determined by the number of pixels in the picture. To increase
or decrease the size of the picture, the number of pixels has to be
increased or decreased. That is what Publisher and any other picture
processing program does. If the original picture doesn't have enough pixels
in it, they have to be invented. That is why pictures go blocky and
indistinct sometimes.
MSFT started using VML which is IE-centric and in theory was supposed to
serve up the best image depending on which browser viewed the site.
Unfortunately this had mixed results. If you inserted a large image file
into your Pub page and then resized the image box to less than full
scale/size of the original image, then Publisher would make multiple
copies of the image in various formats. It usually made a poor quality gif
image for FireFox and other non-IE browsers. Furthermore, if the original
image file was a large 2 meg file taken directly from your camera for
example, then IE would serve up a small 'sized' version of that file but
it was not resampled and optimized for the web, and it would still be 2
megs, and thus would take as much as 10 minutes for that picture to load
if you were using a slow dial-up connection.
There seems to be a mixture of bunk and half-truths here, mixed with a
dollop of misunderstanding.
Yes, VML is IE-centric in that IE is the only browser which supports it.
That's one of the reasons output from recent versions of Publisher can never
be cross-browser compatible. The generated code has to act in different ways
to suit different browsers. VML itself doesn't have much impact upon
pictures - it's used for generating vector based graphics and special
character manipulations which can be drawn or perfomed mostly in Word and
Powerpoint, and also in Publisher. It was implemented in the html generation
engine, which is now common across the Office suite, to generate web pages
which look as close as possible to their equivalents in Word and Powerpoint.
It was not possible to do this in non-Microsoft browsers which don't support
VML, so for those browsers a gif image is generated instead. None of this
has any impact upon images imported from digital cameras.
MSFT introduced the 'compress pictures' tool with the Office 2003 SP1. Now
you could choose to compress or 'resample'
That's true, but other bug fixes were much more significant. In Pub 2007, I
don't think the 'compress pictures' has any effect on jpeg pictures in web
pages. It certainly does on pictures in print pages though - I would
recommend exercising extreme care in using it as it has the potential to
seriously damage the quality of your final output.
that large image so that it was reduced in both size and weight and an
optimized 96 dpi image was produced when you published your web pages.
This
hmm... David will have to explain what the 'weight' of a picture is...
sounds very clever though.
After a lot of campaigning and screaming from people from this group, and
especially David Bartosik,
He looks like a sensible chap - here's something he wrote about making web
pages with Publisher on his web site:
"How do I get my Publisher web pages to display correctly in all browsers?
Basically you don't. Publisher is designed to exploit the technologies of
the Internet Explorer browser. Support in a non Windows IE browser is
limited at best. It is a limitation of using Publisher for a web site."
'compress picture' tool came built-in with Pub 2007. This 'compression'
process also results in a better version of the image for FF...usually the
same image that is seen in IE.
err.. more magic here. The 'same' image is somehow better in Firefox...
As an aside, 'compression' never results in a better quality image, unless
it is of the 'lossless' variety, which this isn't. It involves throwing data
away which has to be reinvented later - minus the detail which was there
originally. The reader may have heard of jpeg 'artifacts' - this is the
process which creates them.
After pushing hard during the beta testing of Pub 2007 by myself and
others,
I somehow doubt it.
MSFT also removed much of the VML coding options from the html coding
engine in Pub 2007.
They may have removed the variable settings, but they certainly didn't
remove the VML, and have stated they have no plans to ever do so. What they
did do was to reduce some of the code bloat by removing code put in by the
other programs in the office suite which allows full 'round tripping' - i.e.
subsequent re-editing of the generated html as if it were the original
document. This they labelled 'filtered html'. The unfiltered variety was
really only intended for use within corporate intranets and shouldn't be let
out on the internet at large.
This eliminated a lot of the most common image problems in Pub 2003 and
much of the browser compatibility issues with non-IE browsers.
Well it must have been really, really bad before....
However all the VML has not yet been stripped out of the coding engine.
One thing that still hasn't been fixed is the way the VML handles word art
and some pictures such as your banner picture with the fancy borders.
Microsoft have said its there to stay, and who says it needs fixing? I'm
sure it works very well at what it was designed to do, which is not to work
in anything other than IE (but not IE8, apparently. Whoops). Microsoft have
a track record of reversing earlier dicisions which turned out bad though,
so it's not entirely out of the question that things might improve. That
might be by the complete removal of web publishing facilities from Publisher
though, which would very effectively solve the problems with very little
effort.
As you noticed Pub 2007 choked on that image and produced a bad, low
version copy. I mentioned when we were discussing this that there was a
workaround, and there is, but it is beyond the scope of this message.
i.e. He's not going to tell you what it is.
The bottom line is that if you understand how the different versions of
Publisher handle and process images, you can get good images generated for
IE and FF and thus most browsers.
i.e. he doesn't - try reading these:
For more information and explanation read the following:
Reference: Compress graphics file sizes to create smaller Publisher Web
pages (2003):
http://office.microsoft.com/en-us/publisher/HA011266301033.aspx
Reference: Compress Pictures dialog box (2007):
http://office.microsoft.com/en-us/help/HA100363901033.aspx?pid=CL100605171033
And this is a pretty good article about VML graphics:
http://www.rxs-enterprises.org/tests/vml-graphics/
It doesn't really look like David actually read them though, as none of them
help much, and bits of them contradict what he's written.
I've had enough of this crap now though.
I'm sure somebody will learn something from all this, if not David.
