Wrong position of animations in ie8

[CordW]

Hello,

my 30 page website, created with publisher 2003, works fine in IE6, IE7,
Firefox. In IE8 my flash animations get a wrong position. They are
positioned left and below the intended position. It seems, as if my intended
position informations (pixel) are somehow multiplied by the Faktor 1.25. In
addition the animations are scaled by approxemately the faktor 1.3. The
scaling is independend of the intended position of the animation.

I integrated the animations via the codefragment functionality of publisher.
This is the code:

<object classid="clsid27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,16,0"
width="160" height="120" >
<param name="movie" value="kurvengetriebe_160x120p.swf">
<param name="quality" value="high">
<param name="play" value="true">
<param name="LOOP" value="true">
<embed src="kurvengetriebe_160x120p.swf" width="160" height="120"
play="true" loop="true" quality="high"

pluginspage="http://www.macromedia.com/go/getflashplayer"
type="application/x-shockwave-flash">
</embed>
</object>


The compatibility option in IE8 has no effect on this problem.
I also integrated the statement

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/>

in the head element as recommended by microsoft. No effect as well.


Can anybody give me an advice how to fix this problem?

Thank you in advance


CordW

 

[DavidF]

Please post the URL to the web page.

DavidF

 

[CordW]

webpage: www.wohltmann-simulation.de

DPI setting: 120 dpi.


CordW

 

[DavidF]

Also, go to Control Panel > Display > Settings > Advanced and see what your
'DPI setting' is for your Display. 96 or 120 dpi?

DavidF

 

[DavidF]

Change the setting on your computer to 96 dpi and republish.

DavidF

 

[CordW]

Hello DavidF,

thank you for your quick reply.

That solved my problem with the ie8 but created a similar one in ie7.

In ie8 the positions of my animations are now correct. The size ist still
too big but I could correct that in publisher. In firefox everything is fine
as it was before. In ie7 I seem to have the opposite effect I had in ie8. The
positions of the animations are now moved to the left und up and they have a
smaller size than intended.

Is there a possibility in publisher to create code fragements that are
recognised by ie8 only? In this way I could provide "corrected" position and
size values for animations in ie8.

Do you have any other ideas how to fix this problem?


CordW

 

[DavidF]

CordW,

I don't have a good solution for you, but can offer some ideas to try, but
first an explanation and some background.

Publisher outputs its html code at 96 dpi and uses absolute positioning, and
VML in its html coding. Until recently all monitors and laptop screens came
preset at 96 dpi, and thus the Publisher web pages rendered correctly at 96
dpi, or more precisely at 96 ppi. (pixels per inch and dots per inch are
used interchangeably here and confuses things). Anyway, with the new high
resolution laptop screens and monitors available today, some manufactures
ship with the display setting at 120 dpi and this can create some problems
with Publisher web pages. As you noted images can be increased or decreased
in size by a scale of about 125% (120/96 = 1.25). Most of the time this is
not obvious to the viewer as they are not comparing the pages side by side,
and the layout of the page is not affected. Also different browsers
accommodate or interpret this difference in dpi and the absolute positioning
in different ways, but once again the viewer is not switching from browser
to browser and won't know there is a difference. Most of the time this issue
of 96 dpi vs. 120 dpi does not create a major problem, but in your case it
has.

From my testing, and my limited understanding of this issue, embedded or
inserted images are less prone to have problems than when you import an
image into a Publisher page. When you insert an image, Publisher will make a
copy of that image when you produce your html code. When you Publish to the
Web the html coding engine will treat all inserted images the same on a
page, by scaling them up or down depending on the display setting you have
on your local machine. However when you import an image(s) such as you are
doing with your swf files, those images are not directly impacted/scaled by
the Publisher coding engine. The image placeholder box on the page may be
scaled, but the actual images are not going through the coding
engine....they are being directly imported to the page...not being scaled.
In your case the images or swf files are not matching up with the image
placeholder in size, and thus are being displaced when rendered by IE.

Ok, so what does all this mean to you. It means I don't have a good solution
for you, but will offer some alternatives and some experiments to try. It
also means that if you want to use these swf file animations, you may need
to switch to different software to build your site.

The first experiment would be to try changing the coding to accommodate the
scaling that is going on. Right now you have 160 X 120 pixels in the coding.
However note the dimensions of this image:
http://www.wohltmann-simulation.de/index-Dateien/image5611.jpg . It is 165 X
125. I would try changing the coding to 165 X 125 as one experiment. I would
make the code fragment boxes on the Publisher page where you are importing
the swf files 165 X 125 as another experiment. I would see if you could drop
the specific height and width out of the inserted code and see if you can
import variable size image. In other words, play with the coding and the
code fragment size to see if varying it will help. I am not a coder, but
also check to see if there is any way to change the flash coding to produce
a variable width and height.

Assuming that you are not able to adjust the coding or the code fragment
boxes to fix the problem, the first workaround to consider is to insert
fixed images instead of swf animations to your page. I noticed that the swf
files are anywhere from 400 kb to 600+ kb. These are relatively large files
which take a long time to load. Each one took over 2 to 3 minutes to load
with my dial up connection. I would never stay on your page long enough for
those images to load, and I am not sure a person with a broadband connection
would either. Perhaps it would be better to use a single images. For example
http://www.wohltmann-simulation.de/index-Dateien/image5611.jpg is less than
6 kb in size. In other words, if you can live without the animations and
substitute in the fixed width images your pages will render correctly,
albeit at different scales depending on the browser.

If as I suspect, the swf simulations are deemed essential for your website,
your best choice is to move away from Publisher. Publisher can be a good
choice for relatively simple static sites, but by introducing the swf
animations into your web, this may be time to look at different software.
Look to a full web editors such as MSFT Web Expression or Dreamweaver, or
perhaps look at Serif Web Plus to see if it can accommodate your animations
more correctly. It is the most similar to Publisher that I know of. I would
look for ways to reduce the size or number of those swf files to decrease
loading time regardless of what program you use.

There you go. I had hoped that a simple one sentence instruction of changing
your display to 96 dpi would work for you, but it didn't. So hopefully this
long answer will give you some insight into what is going on in the
background and a better understanding of the problem. I don't pretend to
totally understand the complications caused by the 96 vs 120 issue, but in
your case it has created a major problem in how your page is rendering.
Hopefully something I have said or suggested will lead to a solution with
Publisher. If it does, let us know. Good luck.

DavidF

 

[CordW]

DavidF,


thank you very much for your explanations and help.

I tested some of your suggestions:
The change of the size of the code fragment box has no effect.

Up to now I didn't find a possibility to change the code fragment in order
to produce better results. There would be a possibility if IE would recognise
conditional comments like <!-- [if gte IE 8] ... <! [endif] -->. But in the
code produced by publisher I don't get that to work.

Probably this is due to the fact, that I'm not an expert in html - and I
don't wont to spend the time to become one. So, although I'm quite sattisfied
with publisher up to now, probalby I will follow your advice and look for
another programm.

Regarding the .swf file size: most of my customers have braodband internet
connections. And with that it usually takes less than 5 seconds until all of
my animations start.

If I should find a solution with publisher I will let you know.


CordW

 

[DavidF]

Thanks for the feedback. Sorry you weren't able to find a solution.

It is less than optimal, but you can use fixed images instead of animations
until you find alternative software.

Good luck.

DavidF

DavidF,


thank you very much for your explanations and help.

I tested some of your suggestions:
The change of the size of the code fragment box has no effect.

Up to now I didn't find a possibility to change the code fragment in order
to produce better results. There would be a possibility if IE would
recognise
conditional comments like <!-- [if gte IE 8] ... <! [endif] -->. But in
the
code produced by publisher I don't get that to work.

Probably this is due to the fact, that I'm not an expert in html - and I
don't wont to spend the time to become one. So, although I'm quite
sattisfied
with publisher up to now, probalby I will follow your advice and look for
another programm.

Regarding the .swf file size: most of my customers have braodband internet
connections. And with that it usually takes less than 5 seconds until all
of
my animations start.

If I should find a solution with publisher I will let you know.


CordW

CordW,

I don't have a good solution for you, but can offer some ideas to try,
but
first an explanation and some background.

Publisher outputs its html code at 96 dpi and uses absolute positioning,
and
VML in its html coding. Until recently all monitors and laptop screens
came
preset at 96 dpi, and thus the Publisher web pages rendered correctly at
96
dpi, or more precisely at 96 ppi. (pixels per inch and dots per inch are
used interchangeably here and confuses things). Anyway, with the new high
resolution laptop screens and monitors available today, some manufactures
ship with the display setting at 120 dpi and this can create some
problems
with Publisher web pages. As you noted images can be increased or
decreased
in size by a scale of about 125% (120/96 = 1.25). Most of the time this
is
not obvious to the viewer as they are not comparing the pages side by
side,
and the layout of the page is not affected. Also different browsers
accommodate or interpret this difference in dpi and the absolute
positioning
in different ways, but once again the viewer is not switching from
browser
to browser and won't know there is a difference. Most of the time this
issue
of 96 dpi vs. 120 dpi does not create a major problem, but in your case
it
has.

From my testing, and my limited understanding of this issue, embedded or
inserted images are less prone to have problems than when you import an
image into a Publisher page. When you insert an image, Publisher will
make a
copy of that image when you produce your html code. When you Publish to
the
Web the html coding engine will treat all inserted images the same on a
page, by scaling them up or down depending on the display setting you
have
on your local machine. However when you import an image(s) such as you
are
doing with your swf files, those images are not directly impacted/scaled
by
the Publisher coding engine. The image placeholder box on the page may be
scaled, but the actual images are not going through the coding
engine....they are being directly imported to the page...not being
scaled.
In your case the images or swf files are not matching up with the image
placeholder in size, and thus are being displaced when rendered by IE.

Ok, so what does all this mean to you. It means I don't have a good
solution
for you, but will offer some alternatives and some experiments to try. It
also means that if you want to use these swf file animations, you may
need
to switch to different software to build your site.

The first experiment would be to try changing the coding to accommodate
the
scaling that is going on. Right now you have 160 X 120 pixels in the
coding.
However note the dimensions of this image:
http://www.wohltmann-simulation.de/index-Dateien/image5611.jpg . It is
165 X
125. I would try changing the coding to 165 X 125 as one experiment. I
would
make the code fragment boxes on the Publisher page where you are
importing
the swf files 165 X 125 as another experiment. I would see if you could
drop
the specific height and width out of the inserted code and see if you can
import variable size image. In other words, play with the coding and the
code fragment size to see if varying it will help. I am not a coder, but
also check to see if there is any way to change the flash coding to
produce
a variable width and height.

Assuming that you are not able to adjust the coding or the code fragment
boxes to fix the problem, the first workaround to consider is to insert
fixed images instead of swf animations to your page. I noticed that the
swf
files are anywhere from 400 kb to 600+ kb. These are relatively large
files
which take a long time to load. Each one took over 2 to 3 minutes to load
with my dial up connection. I would never stay on your page long enough
for
those images to load, and I am not sure a person with a broadband
connection
would either. Perhaps it would be better to use a single images. For
example
http://www.wohltmann-simulation.de/index-Dateien/image5611.jpg is less
than
6 kb in size. In other words, if you can live without the animations and
substitute in the fixed width images your pages will render correctly,
albeit at different scales depending on the browser.

If as I suspect, the swf simulations are deemed essential for your
website,
your best choice is to move away from Publisher. Publisher can be a good
choice for relatively simple static sites, but by introducing the swf
animations into your web, this may be time to look at different software.
Look to a full web editors such as MSFT Web Expression or Dreamweaver, or
perhaps look at Serif Web Plus to see if it can accommodate your
animations
more correctly. It is the most similar to Publisher that I know of. I
would
look for ways to reduce the size or number of those swf files to decrease
loading time regardless of what program you use.

There you go. I had hoped that a simple one sentence instruction of
changing
your display to 96 dpi would work for you, but it didn't. So hopefully
this
long answer will give you some insight into what is going on in the
background and a better understanding of the problem. I don't pretend to
totally understand the complications caused by the 96 vs 120 issue, but
in
your case it has created a major problem in how your page is rendering.
Hopefully something I have said or suggested will lead to a solution with
Publisher. If it does, let us know. Good luck.

DavidF