Spike,
Thanks for the details about the line spacing and the "style". I agree that
it would be better if Publisher webpage templates had default styles that
are "web friendly", much as the available fonts are limited to web friendly
fonts by default. At least there is a fix.
Now as to the camera image on
http://www.technicalsystemsaz.com/FF/camera.htm :
I have experimented a lot with how Publisher handles images, but some of it
is still a mystery to me. Publisher 2007 does make copies of the
inserted/embedded images when you create your html files. It also sometimes
makes different copies of the same image in various formats, and resolutions
with the goal of serving up the best image depending on the browser used to
view the page....with dubious results. While I don't understand all the
specifics, much of the problem is with VML graphics that are "optimized" for
IE. As a result of a lot of feedback in the Pub 2007 beta, Pub 2007 was
changed. If you go into Pub 2003 Tools > Options > Web tab, you will see the
option to "allow VML..." and this was removed in 2007. This helped immensely
in getting Pub web pages to render more correctly in FF and other non-IE
browsers. However, not all the VML coding has been removed from the
Publisher html coding engine, even in Pub 2007.
With that back-story, I have found a few "guidelines" to deal with images in
Publisher. First of all, it seems that images are less likely to be of poor
quality in FF if the images are inserted at 100% scale in the Publisher
page. I accomplish that by sizing and optimizing the image in a third party
image editor prior to inserting it, but in some cases you can also
accomplish much the same thing by using the compress graphics feature before
you Publish to the Web and produce the html files.
Open your Pub file, and select the image of the camera. Format > Picture >
Size tab and look at the information under Scale. The goal is to have the
image at 100% scale. The ideal is to have the height and width the same as
the original size. If you click the "Relative to original picture size"
option, the scale should stay at 100%. (Also keep the aspect ratio locked as
a general rule.) If the scale is something else, then when you produce the
html the image that is produced for FF is usually pretty bad quality....like
your camera picture. If you go to the Picture tab, at the bottom under Image
control is the option to Compress... (also on the image toolbar). If you
click the Compress button, you get a Compress Pictures dialog. You can
probably check all the Compression options, and choose the Web option under
Target Output. And at the bottom of the page you have the option of applying
to all or just the selected picture. The resized and resampled image that
results is generally better quality in the FF, and certainly is a much
smaller file size and loads faster. Try the compression feature on your
camera picture and see if that offers a better quality image in FF. Of
course if you are trying to increase the size of an inserted image, you
won't be happy with the results either...I am talking about downsizing.
One thing to keep in mind is that Publisher outputs images at 96 dpi when
the images are compressed for the Web. If you optimize your image in a third
party graphics program, many times the built-in optimization for the web
tools will resample and resize the image to 72 dpi. If you insert that image
into your Pub page and Publish to the Web, then Publisher will copy and
convert it to a 96 dpi version, and once again you get less than optimum
results. It isn't so bad that you might notice that much difference, but it
is different.
I have also found that Publisher simply chokes on some transparent gif
files. In that case if the if the image is important to me, I will import it
rather than insert and embed it, and thus bypass the coding engine
altogether. This probably gives me the bestest results...I resize and
optimize my images, even to 72 dpi, and then import them into the page and
the image renders exactly as I made it. This is tedious and probably
overkill for most people, and I am not sure the difference in quality, file
size and loading speed is that much better than if you just use the Compress
graphics feature in Pub 2007 on inserted/embedded images...but you might
keep it in mind if you just can't get a particular graphic to look right in
FF. You might also try a transparent PNG instead of GIF, but I have not
researched or tested this. In fact, I tend to avoid PNGs, and always disable
that option....partly out of ignorance about PNGs, but also because they
tend to be a larger file size and load more slowly....from my limited
testing.
Now as to your gradient fill being rendered so badly in FF... As I
suggested, I think the biggest reason for that is that you have the
background text box that you created with the gradient fill overlapping into
the scratch area. That needs to be fixed. Don't allow anything to overlap
into the scratch area. With that said, Publisher has always had some
problems with gradient fills, even in print publications. However, it can
work better than it has in your case. Note the use of a gradient fill
background in the 2saint's site:
http://casagrandecyclones.com/ in IE and
then in FF. In FF on my machine it is a bit "striated", or less than
perfect, but it does suggest a possible work around for your pages. Instead
of the squiggly green lines in the background, go to Format > Background and
choose one of the gradient fills. Once again, the results aren't perfect,
but they should be better than what you have now. You can experiment with
More Backgrounds to see if you can get a background effect that is better
for you, but one way or the other, I would probably try to get away from the
"background text box with fill" that you are currently using. For one thing,
that way of providing a background fixes the page length, where the regular
background method keeps the variable page length feature of Pub pages.
Nuff....I have already written more than you probably wanted to read, but I
figure I owe you and Jo a bit more in time because of your work with the
centering code...thanks again.
DavidF