WYSIWYG

S

Spike

WYSIWYG is WYSI not WYG when using publisher 2007 and MSIE or FireFox

A simple sample is at www.technicalsystemsaz.com/camera

The above is a sample part of a page that I am having a problem with. In
Publisher the text fills the vertical area of the camera picture. In MSIE 7
the test only covers approximately 80% of the vertical area. Thus there are
white spaces between objects and text boxes unless I overlap items. So in
MSIE 7 I have a fix (sort of). Then someone used FireFox on the page and
there are more issues. The text overlaps objects and the background is
distorted.

The real life page that shows it all is:
www.technicalsystemsaz.com/design
With MSIE there are no white spaces and no overlaps
With FireFox the text and graphics overlap and the background is messed up.

Any ideas? Any posts that cover this already (I did not find one)?

But thanks to this forum and the users the pages are centered :)

Spike
 
D

DavidF

HiYa Spike,

First http://www.technicalsystemsaz.com/camera :
I have the dubious advantage of watching this page load slowly with a
dial-up connection. As far as the space between the image and the text box,
part of that is that the image has transparent space around it. If you open
the image in an image editor you will see the area to the right of the
actual image. The text box also has a default margin from the sides and the
top and bottom. Unless you changed that, it is 3.8003 px. Between the extra
transparent area on the side of the image and the margin in the text box,
the two design elements will have some space between them when you produce
the html.

You can change the side margins by going to Format > Text box > Text box tab
and changing the margins there. And I suppose you could crop your image a
little tighter on the sides if you want the two design elements "closer".

As per the vertical space taken by the text varying, I suspect that you have
varied the line spacing by going to Format > Paragraph and tried to increase
the spacing between the lines from 1, so that it looks better to you in the
Publisher file. It also takes up more vertical space, but when you convert
to html, Publisher reverts back to single space when it converts to html,
and thus the text box now takes up less vertical space...it tis shorter.
This is an example of one of those print formatting techniques that works
fine in print, but doesn't in a web publication. The Publisher coding engine
chokes on trying to add spacing between the lines. In general don't use
special paragraph formatting in a web page.

Now as per www.technicalsystemsaz.com/design:

I think your problem with this page being so messed up in FF has to do with
the gradient filled text box with the border that you have tried to use as a
"background". You know I am not much for reading code, but it appears that
you have your page setup as 760 pixels wide. And yet that background image
is 1442 X 1347, which also makes your page width that wide, instead of 760.
See http://www.technicalsystemsaz.com/design_image318.gif . I suspect that
you have overlapped that "background" into the scratch area. Run the design
checker and it will likely flag it, otherwise, enable the Snap To function
in Publisher. Arrange > Snap and check all three options. Now when you pull
the side of the text box toward the edge of the publication it should just
snap to the edge and not overlap. And you might consider removing the
border. Most pages do not have a border around them, especially if you are
trying to use a gradient to "soften" the edges.

Fix the gradient text box, and see if that doesn't fix the problems you are
having. And if I missed the point, or you have other issues, please post
back.

DavidF
 
S

Spike

David

Thanks for the reply:

My paragraph default in 2007 is 1.21 line spacing.

I changed it to 1 and still when publishing to the web as an htm or html
file the vertical size of the block of text is smaller. Also I noticed that
the words on each line are not always the same. Some words end up on the
nest line. I went to less than 1 line spacing and the results follow even
smaller. I do not get a line spacing of 1 as a default when published. It
appears that the font size becomes smaller when published. I am using
Verdana which is a web font. The saga continues. As for the rest of your
reply, YES I did play around with the pseudo background. I am aware that
that it is out of the ordinary. I was asked to do a fade from screen edge
to edge and the background function left me with sharp lines as we are using
different size monitor widths and resolutions. I do use design checker and
it did tell me exactly what you said about the over sized image. At the
present time we have a tag line on the opening page "Best when viewed with
Microsoft Internet Explorer". So I am back at square one. FF is a thorn
in my side. David, I do appreciate you response. Sometimes my pickiness
causes more problems than I am worth.

Since Publisher 2007 and MSIE are are in house programs they can be made to
work together with some maneuvering. Not so lucky with FF.

Spike
 
S

Spike

DAVID ~!

WOW you hit on it. I took your suggestion and cleared the format. Well,
that left me with default which is Georgia Font at 9.2 with line spacing at
1.12.
WYSI not WYG using MSIE 7

So I created a NEW style Verdana 10 with line spacing at 1 based on normal
We have WYSIWYG YEAH!!!!!

Then I started playing with the style i.e.. font size etc I went to odd
numbers and and non integers. Some sizes OK while others are just a tick
off but usable. I am much further ahead than I was before your input and
creating new styles. THANK YOU! Resizing the text box has a slight
effect on some text positioning. A word may be on one line in publisher but
fall to the next line in MSIE. I can live with that one. The line spacing
and the white space are now the same.

Cannot change line spacing, you are correct that it must be set to 1 (as far
as I tested) Why the default is 1.12 is a mystery. I would think that the
web selection would have reset it to 1. MS needs to address that one.

I fired up fire fox and viewed the camera page now they are the same TEXT
wise. I did noticed that the image (transparent gif) was different. It did
not display as well in fire fox as it did in MSIE 7. Can't win them all.
www.technicalsystemsaz.com/FF/camera.htm is where I put the latest test.

I will work on the main site next (create all new styles).

Then I am off to work on a common background. Fire fox did the same thing
to the background as it did to the transparent image.

I will let you know what I come up with !!

Hope the efforts we made here can assist others.

Spike
 
S

Spike

Good info
Web fonts was a consideration early on and that is why I ended up with
Verdana
Thanks
Spike
 
M

Mike Koewler

DAvid,
I think I also remember reading somewhere that different fonts are
rendered slightly different sizes by IE and FF.

You remember correctly, or close to it sir! IE and FF look at font sizes
and line spacing differently. I don't recall which one does what, but
using a font with a point size of 9.1 will be honered by one browser but
converted to 9.0 in another. Ditto for using line spacing at 102 percent.

Mike
 
D

DavidF

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
 
D

DavidF

Its rough getting oldererer. I can't seem to remember a lot of things some
days...I think it was Tuesday. ;-)

Thanks.

DavidF
 
R

Rob Giordano \(Crash\)

Points are a print metric so you'll hve problems when using them...you
should use px, %, em, or named sizes like; small etc.
Of course you don't have these choices with Publisher because it's designd
for print!



--
~~~~~~~~~~~~~~~~~~
Rob Giordano
Microsoft MVP Expression
 
S

Spike

David ~!

Just discovered that the MAC Apple machine does the same thing that Firefox
does. It does not like the gradient fill either.
I did change all the fonts to even numbers and now there is no overlapping
of graphics and text.

Thanks for the assistance

BTW: it's getting warm here in the Great Sonoran Desert. We will just turn
up the AC and build more web pages.

Spike
 
D

DavidF

Spike,

Thanks for the feedback. Your experience seems consistent with others. If
you can get a page to look ok in FF, then it will look ok on a MAC. That is
part of the reason I keep preaching that Publisher webs should be tested in
IE and FF. If you get those covered, you have got most browsers
covered...including MACs and Opera browsers.

I still think you need to get that background text box with the gradient
removed....or redesigned. When you apply a gradient fill in Publisher as you
did it actually uses a long skinny "line" that has the gradient and then
expands that line or widens that line to fill the text box with the
gradient....I think. The effect works fine in IE, but not as well in FF. In
FF it ends up looking a bit like what happens when you enlarge a small
image...the larger the image, the more pixilated it gets. The "enlarged"
gradient line leaves some "banding" or "striations" in most cases when you
view in FF. In your case, you have overlapped into the scratch area and are
getting even worse.

If you insist on trying to use some gradient, and don't want to put it in
the background instead of the green curly design, then you may always have
this problem. However, you might also consider breaking that text box up
into two text boxes and applying the gradients to those, with one fading to
the left, and one fading to the right. If the text box is half as wide, you
might get less distortion of the gradient...just an idea.

DavidF
 
S

Spike

WOW David

That is scary! I was just about to try the left and right individual
textured boxes. Was formulating a plan in my mind and then decided to look
at this forum before I started the procedure of testing same and your
message popped up. The "Client" wants the faded sides. Can't talk them out
of it so far. The "Client" is always right, Right? They (Client) tell me
that I am like a dog on a bone. I will chew that thing until there is
nothing left. If I haven't solved the issue I get another bone and start
chewing. That seems to be the atmosphere of this forum. The answer is out
there somewhere just waiting to be found. I have done some web searching
on other forums and the issue is there without a solid solution YET !

Spike
 
S

Spike

David ~!

It worked ....

I split the boxes, shaded them and positioned them to cover 1024 pixels +
Any monitor set over that will have a line at the edge. Most people I have
canvassed use 1024 and less.

I tested it with FF and MSIE looks the same. I will have a friend with a
MAC check it out as well.

The client is looking it over and hopefully they will approve it.

When we post I will let you know. It is in a sub folder at the present
time.

THANK YOU :) You (we) did it.

Spike
 
M

Mike Koewler

Spike,

I don't go by the people I know - I go by my log files. Close to 30
percent of the visitors to my sites (4 different ones, covering a wide
variety of topics) have 800 x 600 or less.

Do you really want one out of three visitors to you site have to put up
with a horizontal scroll bar?

Mike
 
D

DavidF

What ever floats your boat, but I agree with Mike. I think it unwise to
design a page that wide. I am not sure how it will work with the centering
code either. I guess if you have to, then make sure the content is less than
800 pixels wide stays to the left of 950 pixels, so that people won't have
to scroll sideways to read the content. I guess I still don't understand why
you don't just replace the squiggly green lines you have in the background
with the gradient. Then it will fill whatever size window the user is
viewing the site in, and your centering code will work. Plus it seems that
the gradient does work in the Background even in FF. But, like I
said...whatever floats your boat.

DavidF
 
S

Spike

Thank you David and Mike for the candid remarks.

I agree 100 %. I am trying to please someone who wants a particular
background appearance. I passed this along to them and I believe that they
will ease up on their desires. I also found something else that was a
problem that I created unknowingly and may be of use to someone else here on
the forum. I am using a wide screen monitor set to 1440 by 900 resolution.
The background I am using injects the code that follows:

fillcolor="#06f" o:targetscreensize="1400,900">

So when I look at it at a resolution of 1024 by 768 or less the shading is
offset rendering the left of the screen darker than the right.

By changing the screen resolution on the computer before I publish the files
I get

fillcolor="#06f" o:targetscreensize="1024,768"> (or what ever I set the
resolution to)

This only happened using Publisher 2007 It does not happen using publisher
2002

Spike
 
D

DavidF

Spike,

That appears to be associated with the gradient background, as the only time
I get "o:targetscreensize" in the code is when I produce code with a
gradient.

DavidF
 
S

Spike

David Rob Mike and any and all others

I put this one to bed

Thanks for all your inputs!!!

The client wanted the background as it was. SO, I left it alone for IE 5.0
and above users. Non IE 5.0 and above users are directed to a sub folder
showing the same web site without the background in question. I
accomplished this with a java script file that looks at the browser
information of the user and directs them to the appropriate folders.

A win win and everybody is happy.

Spike
 
D

DavidF

Congrats and thanks for sharing...

DavidF

Spike said:
David Rob Mike and any and all others

I put this one to bed

Thanks for all your inputs!!!

The client wanted the background as it was. SO, I left it alone for IE
5.0 and above users. Non IE 5.0 and above users are directed to a sub
folder showing the same web site without the background in question. I
accomplished this with a java script file that looks at the browser
information of the user and directs them to the appropriate folders.

A win win and everybody is happy.

Spike
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top