Images in Publisher websites

[GeoffreyChaucer]

A general tip for users of Publisher 2000 and 2002:
(this may also be valid for Pub 2003 and 2007, but I’m not sure)

Avoid inserting any photo or graphic directly on your Publisher construction
pages.

First step, create a website container-folder on your local disk and inside
it create an image sub-folder for each page, plus one common folder for such
images common to all pages, such as logos, rollovers for menus etc.

For example you could name the folders: common, homepics, page2pics,
page3pics, etc.

Second step, prepare all your photos and graphics by resizing them to the
required display size, using a graphic/photo editor. This will minimize
download time when the original image is very large. Then save all your
photos and graphics in the appropriate folder.

The third step paradoxically requires you to insert the pictures on the
construction pages and dragging each one in the desired position. Then click
on tools and activate the “Snap to Object†tool.

Next, using the HTML fragment tool, draw a fragment box around each picture
and insert the following code:
<img src=â€foldername/imagename.type of picture(jpg, or gif, or png, or bmp)â€>

If the image is a link use the following code instead:
<a href=â€fullpathURLâ€><img src=â€foldername/imagename.typeofpictureâ€
border=0></a>

After each html fragment is coded, click on the send to back icon on the
top tool-bar. Finally, click on the actual picture, which should now be on
top, and delete it, leaving only the html fragment box.

When all the textual content has been inserted on your pages, click “Fileâ€,
then “Save As Web Page†into the website container-folder, then open the
container-folder and upload via ftp the entire content of this folder to your
server.

 

[DavidF]

Geoffrey,

Why is it better to import images into a Publisher web and important to
avoiding inserting or embedding images? What you propose doing is a lot of
work. What is the advantage?

DavidF

 

[GeoffreyChaucer]

David,

This relates to Pub 2000 & 2002 which generate neither supporting folders
nor site-manager.

There are several advantages. The first is that the pages download quicker
on ISDN connections.

The second is that it provides a clean structure to work with on both the
local disk and the server, instead of having a mess of html files mixed up
with a large number of image files; it makes it a lot easier to maintain the
site and update individual pages, especially with regard to transient content.

The third is that the quality of images remains intact. Occasionally and in
some cases frequently, images get slightly distorted when dragged into
position on the construction pages (at least, that has been my experience).

As to the perception that this is a lot of work. There's nothing to it. The
folder structure is created in 2 minutes, say five minutes for a very large
site.

The way I described the creation of html fragments boxes was for a
first-timer. An experienced user would do this in minutes, by simply "copy
and paste" and resizing the boxes to suit each image then changing only the
folder name and/or the image name.

 

[DavidF]

Geoffrey,

Thanks. I think I understand your logic now. I have admired your "iframe
style" websites which also require a thorough understanding of how to import
other pages and elements into a Publisher page. I have kept links to the
sample webs you have provided to learn from them.

I am not convinced that the average user will find your approach as easy as
it is for you or will find the results worth the added work and time. Never
the less, thank you for sharing it.

DavidF

 

[GeoffreyChaucer]

David,

An iframe is simply a window inside a webpage that allows another webpage to
be displayed in that window.

You create the iframe in an html fragment box. The box must be made to the
size you require for the external document and the width and height in pixels
must be specified in the iframe tag.

The src="documentname.html (or htm, or any other web format)" statement in
the iframe tag can call a local document or it can call an external document,
in which case you must provide the full path of the URL instead of just the
document name.

Generally speaking, an iframe does not resize to accomodate the content, but
you can make it resizable for variable content by creating it with a script
instead of an html fragment.

I hope this will help.

 

[DavidF]

Thanks for the explanation. I already know how to use iframes and use them
for importing Porta and JAlbum slide shows on my sites rather than opening
the slide show webs in a new window. The reason I have saved your webs are
the other creative ways you have used the iframes in layout and design, and
as examples of what one can do with Pub 2000 and Publisher in general. You
managed to create a 'layered' look without actually layering which won't
work in 2000. As you know if you layer two objects they combine to one image
in 2000. Anyway...I just think you did a good job and use a few techniques
that I have not seen anyone else use...that is why I saved the links to your
sites.

DavidF

 

[GeoffreyChaucer]

Thanks for the comments, David.

Thanks for the explanation. I already know how to use iframes and use them
for importing Porta and JAlbum slide shows on my sites rather than opening
the slide show webs in a new window. The reason I have saved your webs are
the other creative ways you have used the iframes in layout and design, and
as examples of what one can do with Pub 2000 and Publisher in general. You
managed to create a 'layered' look without actually layering which won't
work in 2000. As you know if you layer two objects they combine to one image
in 2000. Anyway...I just think you did a good job and use a few techniques
that I have not seen anyone else use...that is why I saved the links to your
sites.

DavidF

 

[GeoffreyChaucer]

A little precision:

When I said pages download faster on ISDN if the images are in folders, this
applies only to plain pages.

If the pages contain iframes, download time will significantly increase no
matter where the images are. That's the downside of using iframes.

 

[DavidF]

I am still not convinced that images will be of lesser quality or load that
much faster if they are resized, optimized at 96 dpi and embedded at 100%
scale, but I could be wrong...it wouldn't be the first time.

Have you ever tested to see if the loading time of the whole page is
improved by specifying the height and width attributes of the imported
images in your code snippet? I have read a few things that suggest leaving
them out slows the loading time of the whole page...

DavidF

 

[GeoffreyChaucer]

Resizing pictures to the correct display size must be done with a graphic
editor like Photoshop, not with Publisher because it (at least Pub2000)
reduces the size but does not compress image files to the same extent as
proper editors do.

The point is that I have seen people putting very large images say 800 X 500
(80+ kb) specifying the display size in the image tag as 240 X 150, which is
fine. But while the browser will display the image at the specified 240 X
150, it still has to download 80+ kb.

If the image size was reduced to 240 X 150 at the same resolution as the
original, the file size would be less than 20 kb.

As to specifying the actual image size to reduce download time (I read this

 

[DavidF]

I must admit that I have tested how Publisher handles images in all versions
until I was blue in the face over the years, and am still not 100% sure of
the best way. Because I was curious I just tested your scenario again in
Publisher 2000, which handles images differently than newer versions.

I tried to replicate a typical workflow. I took an image that was shot with
a Cannon digital that in it's raw form was 2272 X 1704 @ 180 ppi. and 2,365
kb and inserted it into a blank Publisher web page and sized the picture box
to 400 X 300 pixels. I originally inserted a optimized and resized image
that I knew to be 400 X 300 at 100% scale to create the box, and then
inserted the large raw image in that image box. After doing a 'save as a web
page' and letting Pub 2000 produce its copy of the original, that image
ended up being 400 X 300 as expected and reduced from 2,365 kb to 17 kb in
size and 1440 ppi.

I then inserted an image that I had optimized 'for the web' with Adobe
Photoshop Elements. I started with the original raw image and resized it to
400 X 300 @ 72 ppi and as much compression as seemed possible without
affecting the quality of the image. That image ended up being 14 kb when
inserted, and after publishing it was converted to a 15 kb 400 X 300 @1440
ppi.

I then created an optimized image at 400 X 300 @ 96 dpi and a low quality
compression of 3 and got a 27 kb image. It was converted to a 14 kb @ 1440
ppi.

So, I was wrong with what I had remembered in one way at least. I thought
that when I inserted a 96 dpi image and it was scaled at 100% then I would
end up with a exact copy with Publisher outputting at 96. Instead I get that
weird 1440 ppi setting.

I was right in my memory that even a oversized raw 72 ppi image is
automatically resampled and resized when published.

I was also right in my memory that in all three tests the resulting image
that is produced is close to the same file size and quality.

In the past I had also ran tests of how the quality varied when I imported
the different test images and I agree that if you want to import a fully
optimized 72 ppi image into a Pub 2000 web page you can get a slightly
better quality image, but not a substantially smaller file size or thus
faster loading image...a 14 kb size image is not going to load noticeably
faster than a 17 kb....even on my slow dial-up connection. And even the
improved quality is not that significant in my book. The point being that I
decided for me that I reached the point of diminishing returns when I
resized, resampled and optimized the images in Photoshop Elements prior to
inserting them into my Publisher pages at 100%...and that it wasn't worth
the extra trouble to import them to get a slightly smaller file size and
slightly better quality. The exception to that are banners and other images
that are common to each page. I import them just because it seems a waste to
make copies for each page.

Now, I have been talking about Publisher 2000, but your scenario is more
true for Pub 2003. If I insert my original image of 2272 X 1704 @ 180 ppi.
and 2,365 kb and size the picture box at 400 X 300 and then 'publish to the
web' and produce my web files I get two copies of the image. One is exactly
the same as the original and as you suggested it is the image that is
rendered at 400 X 300 when the page is viewed with IE, but the whole 2.365
meg file loads...and that takes close to 12 minutes for my slow connection!
Meanwhile if you view the site with FireFox then you get the other image
which is 400 X 300 @ 96 dpi and 14 kb. If I run the 'compress pictures'
function the image is resized and resampled and I end up with only the 14 kb
file @ 400 X 300 @ 96 dpi.

Pub 2007 works slightly different. If you have the "allow png.."option
turned on then you get two copies, but if you untick that option you get
only one...

Both Pub 2003 and 2007 could benefit from importing optimized images
directly for improved quality because of the VML used, but the file size
would be about the same as long as you always compressed the pictures.

Anyway, those are my results, and all this is probably a moot issue as there
are only a few of us that still use Pub 2000 anyway. Never the less it was
interesting running the tests again and I can see why you say the images
will be smaller and better quality...but in my opinion not that much smaller
or better quality to rationalize the extra work of importing them...at least
for me.

DavidF

 

[GeoffreyChaucer]

Impressive empirical data, David, and I have no choice but to accept your
conclusions.

However, I still maintain that there are benefits in importing images and
graphics from folders.

1- Imagine having to maintain a website consisting of 70-80 html documents,
200+ images, and a few jscript and css files all contained in a single
directory.

2- While I could be wrong, I observed that the browser's download chronology
seems to change if the images are imported, and the page (background and
textual contents) downloads quicker as the images appear to be downloaded
last.

I must admit that this perception may be affected by my extensive use of
iframes, which DOES alter the download chronology due to the nesting effect.

 

[DavidF]

Hi Geoffrey,

I can see benefits, and especially as the site grows larger as you describe.
One of the limitations of Publisher is that it becomes increasingly more
difficult to manage as the site becomes larger. If you have an 80 page site,
then not only would I consider organizing images into subfolders, but I
would suggest considering breaking the whole site up and building it with
multiple Publisher files and subfolders containing the separate Pub file
html output. You effectively do that now with your use of iframes. I moved
in that direction when my sites started getting bigger and exceeded the
maximum navbar button number of 10 for Publisher 2000. I also went with an
imported javascript navbar...but I digress. Your point is well taken. There
are advantages of using subfolders to organize a larger Publisher website
and the site pages may very well load faster.

Here is a link to an article discussing using multiple Publisher files to
produce a website for others that may be following this thread and be
curious as to the approach. As I said I do it a bit different with
subfolders, but it offers another perspective. Reference: Building a web
site with multiple Publisher web publication files:
http://msmvps.com/blogs/dbartosik/pages/81264.aspx

Thanks for your insights.

DavidF