96 DPI /120 DPI conflict - a possible solution

[robmog]

Those of you on this forum during the earlier part of this year may recall
that my first blundering attempts at Publisher web site design identified an
issue that not many people seemed to be aware of - that pages published on a
computer set at 96dpi would not always display correctly when viewed on a
computer set at 120dpi (particularly in browsers other than IE) and vice
versa. It appears however that I may have stumbled on a solution.

If you use the "group objects" function to group all of the objects and text
boxes together before publishing the page, they will all hold their relative
postions when viewed at a diffent DPI setting. No more mashed up images and
text.

This method is not totally foolproof. Objects created by externally
generated HTLM code fragments will sometimes end up in a different position -
although oddly only in IE, they behave perfectly in Firefox and Opera.
Hyperlinks created by direct selection of text or objects do not seem to
survive the transition to Firefox, however those created by hotspotting do as
long as you remember to include them in the grouping process.

Not the most convienient solution I admit, but it seems to do the trick.
Incidentally I have come across 4 different HTLM editing / web site creation
applications that will not even run on a machine set at 120DPI

Hope this is of some help.

Robert

 

[Mike Koewler]

Robert,

Thanks for adding to the knowledge base. This subject is going to crop
up more as people get new computers with larger monitors. I would hope
the W3C sets some kind of guideline and standard, not the MS would
consider following it.

I use WebPlus and while text created in it does not seem to be affected
by the resolution (except for JS Nav Bar text), it does mess up form
boxes, such as edit boxes or check boxes. A solution for this is to add
style="width:%width%px" at the end of the html code for the edit box:
<input type="text" id="edit" name="Name" size="61" "add code here">

Mike

 

[DavidF]

Good job Robert. Thanks for taking the time to post your workaround.

DavidF

 

[Shaun.Hurd]

Hi All,

I'm just a newbie to this whole website/Publisher business, but after
having some problems displaying our new website on different PC's I
stumbled across this newsgroup - which has been an absolute mine of
information (thank-you all!) I have also been having problems getting
our website to display properly on 120DPI widescreen laptops. I tried
grouping all of the objects on each page as you have suggested, and
although it improved the layout in IE7, I found that it was still not
identical to the original 96DPI layout. The other downside (as you
alluded to, Robert) was that all of the text-based hyperlinks
disappeared in Firefox. The quality of the text and images were also
degraded when viewed in Firefox (something to do with the grouping of
objects?).

However, after a bit of playing around with the HTML code (which I'm
also new to), it looks to me like one of the problems is with the way
that objects are positioned on-screen, using either point or pixel-
based measurements. For example, to display a particular image on our
website, Publisher 2007 generated the following code:

[if gte vml 1]><v:rect
id="_x0000_s1273" style='position:absolute;left:293.25pt;top:
136.5pt;width:312pt;height:57.21pt;
...
</v:rect><![endif]
[if !vml]><span style='position:absolute;z-index:164;left:
391px;top:182px;width:416px;height:76px'>
<img width=416 height=76 src="index_files/image3451.gif"
v:shapes="_x0000_s1273">
</span><![endif]

So from my novice viewpoint, it looks like if VML is used (in IE6 or
IE7, but not Firefox?) then the image is positioned using pt-based
coordinates

("left:293.25pt;top:136.5pt;width:312pt;height:57.21pt")

but if VML isn't used then the image is positioned using pixels

("left:391px;top:182px;width:416px;height:76px").

I found that if I manually went through the HTML code and replaced the
"left" and "top" point coordinates in the VML reference with pixel
coordinates, that the page then displayed correctly at 120DPI. So in
the previous example, I changed the first part of the code to be:

[if gte vml 1]><v:rect
id="_x0000_s1273" style='position:absolute;left:391px;top:
182px;width:312pt;height:57.21pt;
...
</v:rect><![endif]

Note that I didn't change the "width" or "height" scaling factors. I
also didn't have to reposition every object on the page - only the
textboxes and pictures, but not the lines. Obviously this solution
isn't appropriate for a huge site, but for my purposes it only took a
short period of time to complete (our site consists of only 7 pages).
But it looks to me like a simple change to the engine generating the
HTML code would fix a lot of the display problems that are occurring.
And as people have commented before, this is only going to become more
of an issue in the future with an increasing uptake of higher-res
screens.

Shaun

 

[DavidF]

Shaun,

Thanks for your work. Hopefully MSFT will come up with a change to the html
coding engine, and address this issue permanently.

DavidF

Hi All,

I'm just a newbie to this whole website/Publisher business, but after
having some problems displaying our new website on different PC's I
stumbled across this newsgroup - which has been an absolute mine of
information (thank-you all!) I have also been having problems getting
our website to display properly on 120DPI widescreen laptops. I tried
grouping all of the objects on each page as you have suggested, and
although it improved the layout in IE7, I found that it was still not
identical to the original 96DPI layout. The other downside (as you
alluded to, Robert) was that all of the text-based hyperlinks
disappeared in Firefox. The quality of the text and images were also
degraded when viewed in Firefox (something to do with the grouping of
objects?).

However, after a bit of playing around with the HTML code (which I'm
also new to), it looks to me like one of the problems is with the way
that objects are positioned on-screen, using either point or pixel-
based measurements. For example, to display a particular image on our
website, Publisher 2007 generated the following code:

[if gte vml 1]><v:rect
id="_x0000_s1273" style='position:absolute;left:293.25pt;top:
136.5pt;width:312pt;height:57.21pt;
...
</v:rect><![endif]
[if !vml]><span style='position:absolute;z-index:164;left:
391px;top:182px;width:416px;height:76px'>
<img width=416 height=76 src="index_files/image3451.gif"
v:shapes="_x0000_s1273">
</span><![endif]

So from my novice viewpoint, it looks like if VML is used (in IE6 or
IE7, but not Firefox?) then the image is positioned using pt-based
coordinates

("left:293.25pt;top:136.5pt;width:312pt;height:57.21pt")

but if VML isn't used then the image is positioned using pixels

("left:391px;top:182px;width:416px;height:76px").

I found that if I manually went through the HTML code and replaced the
"left" and "top" point coordinates in the VML reference with pixel
coordinates, that the page then displayed correctly at 120DPI. So in
the previous example, I changed the first part of the code to be:

[if gte vml 1]><v:rect
id="_x0000_s1273" style='position:absolute;left:391px;top:
182px;width:312pt;height:57.21pt;
...
</v:rect><![endif]

Note that I didn't change the "width" or "height" scaling factors. I
also didn't have to reposition every object on the page - only the
textboxes and pictures, but not the lines. Obviously this solution
isn't appropriate for a huge site, but for my purposes it only took a
short period of time to complete (our site consists of only 7 pages).
But it looks to me like a simple change to the engine generating the
HTML code would fix a lot of the display problems that are occurring.
And as people have commented before, this is only going to become more
of an issue in the future with an increasing uptake of higher-res
screens.

Shaun

 

[robmog]

I've done a little bit more research into this and it appears that when a 96
dpi site is viewed at 120dpi it is actually the externally generated HTML
fragments that behave correctly (which makes sense) and the Publisher
generated code which shifts around. Firefox seems to be able to interpret
this better than IE. The upshot is that HTML fragments and Publisher
generated code will probably never align correctly when viewed at a different
dpi setting in IE, and this needs to be taken into account when designing a
site. If you can view the front page of www.hendersonlightingdesign.com at
both 96 and 120 you will see that the layout has had to be designed around
the HTML generatedbehaviour of the Flash movie. The 96 version is closest to
what was required but had to be compromised slightly to accomodate the
movie's position at 120.

As for Firefoxes recognition of text selected hyperlinks, it all appears to
be a bit arbitary. Sometimes they will come through and sometimes not. I have
a feeling this is more to do with their layer order when the file is
published.

Incidentally does anyone know why hyperlinks created with hotspots will not
execute files?

 

[Rob Giordano \(Crash\)]

| Incidentally does anyone know why hyperlinks created with hotspots will
not
| execute files?

What are you asking, exactly?
Are you asking about executables? If so...they won't ever execute, for
security reasons.



| I've done a little bit more research into this and it appears that when a
96
| dpi site is viewed at 120dpi it is actually the externally generated HTML
| fragments that behave correctly (which makes sense) and the Publisher
| generated code which shifts around. Firefox seems to be able to interpret
| this better than IE. The upshot is that HTML fragments and Publisher
| generated code will probably never align correctly when viewed at a
different
| dpi setting in IE, and this needs to be taken into account when designing
a
| site. If you can view the front page of www.hendersonlightingdesign.com at
| both 96 and 120 you will see that the layout has had to be designed around
| the HTML generatedbehaviour of the Flash movie. The 96 version is closest
to
| what was required but had to be compromised slightly to accomodate the
| movie's position at 120.
|
| As for Firefoxes recognition of text selected hyperlinks, it all appears
to
| be a bit arbitary. Sometimes they will come through and sometimes not. I
have
| a feeling this is more to do with their layer order when the file is
| published.
|
| Incidentally does anyone know why hyperlinks created with hotspots will
not
| execute files?
|
| "DavidF" wrote:
|
| > Good job Robert. Thanks for taking the time to post your workaround.
| >
| > DavidF
| >
| > | > > Those of you on this forum during the earlier part of this year may
recall
| > > that my first blundering attempts at Publisher web site design
identified
| > > an
| > > issue that not many people seemed to be aware of - that pages
published on
| > > a
| > > computer set at 96dpi would not always display correctly when viewed
on a
| > > computer set at 120dpi (particularly in browsers other than IE) and
vice
| > > versa. It appears however that I may have stumbled on a solution.
| > >
| > > If you use the "group objects" function to group all of the objects
and
| > > text
| > > boxes together before publishing the page, they will all hold their
| > > relative
| > > postions when viewed at a diffent DPI setting. No more mashed up
images
| > > and
| > > text.
| > >
| > > This method is not totally foolproof. Objects created by externally
| > > generated HTLM code fragments will sometimes end up in a different
| > > position -
| > > although oddly only in IE, they behave perfectly in Firefox and Opera.
| > > Hyperlinks created by direct selection of text or objects do not seem
to
| > > survive the transition to Firefox, however those created by
hotspotting do
| > > as
| > > long as you remember to include them in the grouping process.
| > >
| > > Not the most convienient solution I admit, but it seems to do the
trick.
| > > Incidentally I have come across 4 different HTLM editing / web site
| > > creation
| > > applications that will not even run on a machine set at 120DPI
| > >
| > > Hope this is of some help.
| > >
| > > Robert
| >
| >
| >

 

[robmog]

I guess execute wasn't really the right word. I have various videos, images
and pdf's that can be accessed via my sites. If I link to them using text
selected hyperlinks they will automatically open and the right click "save
target as" option is available on the link. If I use hotspots to create the
hyperlinks then they do not open the files and the right click option is not
available. Also having just run some Google diagnostic tools on some of my
sites, I'm not sure that google recognises the hotspots as links. Most of
these sites have links pointing to each other which have been created with
hotspots to avoid the possibility of them being lost in other browsers.
However, google is reporting that none of my sites have links pointing to
them from other sites, although all of my sites have been indexed by Google.

 

[robmog]

I'll try and get my head round your HTML solution but my coding skills are
minimal - thats why I started using Publisher. The image degradation you are
experiencing in Firefox are not nessecarily the result of grouping the
objects. Firefox can be very poor at rendering Publisher objects. Subtly
shaded backgrounds in Publisher can end up looking like checkerboxes in
Firefox.

Thanks

Robert

Hi All,

I'm just a newbie to this whole website/Publisher business, but after
having some problems displaying our new website on different PC's I
stumbled across this newsgroup - which has been an absolute mine of
information (thank-you all!) I have also been having problems getting
our website to display properly on 120DPI widescreen laptops. I tried
grouping all of the objects on each page as you have suggested, and
although it improved the layout in IE7, I found that it was still not
identical to the original 96DPI layout. The other downside (as you
alluded to, Robert) was that all of the text-based hyperlinks
disappeared in Firefox. The quality of the text and images were also
degraded when viewed in Firefox (something to do with the grouping of
objects?).

However, after a bit of playing around with the HTML code (which I'm
also new to), it looks to me like one of the problems is with the way
that objects are positioned on-screen, using either point or pixel-
based measurements. For example, to display a particular image on our
website, Publisher 2007 generated the following code:

[if gte vml 1]><v:rect
id="_x0000_s1273" style='position:absolute;left:293.25pt;top:
136.5pt;width:312pt;height:57.21pt;
...
</v:rect><![endif]
[if !vml]><span style='position:absolute;z-index:164;left:
391px;top:182px;width:416px;height:76px'>
<img width=416 height=76 src="index_files/image3451.gif"
v:shapes="_x0000_s1273">
</span><![endif]

So from my novice viewpoint, it looks like if VML is used (in IE6 or
IE7, but not Firefox?) then the image is positioned using pt-based
coordinates

("left:293.25pt;top:136.5pt;width:312pt;height:57.21pt")

but if VML isn't used then the image is positioned using pixels

("left:391px;top:182px;width:416px;height:76px").

I found that if I manually went through the HTML code and replaced the
"left" and "top" point coordinates in the VML reference with pixel
coordinates, that the page then displayed correctly at 120DPI. So in
the previous example, I changed the first part of the code to be:

[if gte vml 1]><v:rect
id="_x0000_s1273" style='position:absolute;left:391px;top:
182px;width:312pt;height:57.21pt;
...
</v:rect><![endif]

Note that I didn't change the "width" or "height" scaling factors. I
also didn't have to reposition every object on the page - only the
textboxes and pictures, but not the lines. Obviously this solution
isn't appropriate for a huge site, but for my purposes it only took a
short period of time to complete (our site consists of only 7 pages).
But it looks to me like a simple change to the engine generating the
HTML code would fix a lot of the display problems that are occurring.
And as people have commented before, this is only going to become more
of an issue in the future with an increasing uptake of higher-res
screens.

Shaun

 

[DavidF]

First of all you need to remember that Publisher 2003 produces two different
sets of code...one for IE and one for other browsers. It also makes copies
of inserted images in various formats and resolutions, once again with the
idea of providing the "best" image depending upon the browser used to view
the page. Publisher has done this since MSFT "adopted" Publisher into the
Office family, and changed the html coding engine to include VML, starting
with Pub 2002. Sometimes this works ok, but often the more complex the page
design, the more often Publisher chokes on trying to produce code that will
work correctly in other browsers.

Generally the reason any hyperlinks don't work with a Publisher page viewed
in FireFox is that they have been killed by converting text boxes or other
design elements to an image. If you have layered up several images, and
inserted a hyperlink into just one of the images, then its possible that
Publisher has combined all those layered images into one new one, and
thereby killing the link.

Text boxes with hyperlinks that are filled with a color can be converted to
an image. Overlapping or even being too close to other page elements can
result in a combined image. The bottom navbar that is created using the
navbar wizard... In other words, there are lots of potential reasons why a
hyperlink can be killed. You just have to test each case to find out what is
happening and change the design so it works. One quick way to test for text
being converted to an image is to try to select the text by left clicking
and dragging across the text. If you can't do that, it has been converted to
an image. If an image with a link inserted seems to have the link killed,
then in FF, right click the image, and save it to your desktop (you can't
right click an image in a Pub page in IE). Chances are when you look at that
image, it will be a combined image...not the original image. Its also
possible that Publisher simply can't convert an image that has had a
hyperlink inserted, so that it will work in FF. I so rarely insert a
hyperlink into an image, that I haven't tested this.

If you want us to look at a particular case where you are having problems,
then post the URL and the specifics of what is wrong.

DavidF