Re: Publisher 07 Form Won't Work With Mac

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi, David,

Thanks for taking all this time with my picky little problems.

1) I compress photos and other graphics in a separate graphics editor
before inserting into Publisher site. However, I've never used the compress
all graphics function within Publisher. Maybe that's part of the problem.
Will experiment with the PNG as you described.

2) Re text situation in Firefox. Sorry to have inadequately explained what
I was doing there.

On the page About Us, the first and second columns were designed using
different elements.

In column 1, only Word Art was used for section titles: Who We Are and
Section Board Members. The horizontal line under Who We Are is simply a line
added separately via the toolbox. I re-colored it to match.

In column 2, while the section title Sponsors/Advertisers is also Word Art,
the element below it with the text is a Design Gallery Object (Pull Quotes,
Borders design). The Design Gallery Object begins with the black horizontal
line below the Word Art title, and includes the vertical tinted bar on the
left, and a text box. This Design Gallery Object comes pre-designed to match
my current color scheme.

With your explanation about images affecting text appearance in Firefox, I
now see that the reason just that 2nd paragraph shows up clearer than the
original is that I re-boxed it, and Firefox no longer sees that text as part
of the image. (the a-ha moment...!)

My solution, it seems, is to re-box ALL text within all Design Gallery
Objects. Does that make sense to you? I'll give it a try and let you know.

Gee, I guess this is the "fun" part. Unless I'm pulling my hair and
clenching my teeth over issues like this...! <sigh>

Thanks again.
--
Liz4.0


"DavidF" wrote:

Liz,

The problem you are having with your section headings is that Publisher
converts wordart into an image. I should say that wordart is not text to
begin with, and the image that is produced renders more clear and closer to
what the wordart would look like on the printed page in IE than in FF. To
illustrate, load your About Us page in both IE and FF:
http://www.nflaace.org/index_files/Page335.htm

The "Sponsors/Advertisers" heading is an image in both IE and in FF. Try to
left click, drag and select the heading and you can't. If you try to select
text you can. Here is the image in FF:
http://www.nflaace.org/index_files/image683.gif

Now my first reaction was to tell you that you just had to live with this,
but I tried an experiment with IE5 and FF3.0 and found a way to get the FF
image to look more like the IE image. One of the standard pieces of advice I
give is to go to Tools > Options > Web tab and uncheck "Allow PNG...". This
was important, and is important if the user does not use the compress
graphics tool that became available in SP1 or 2 in Pub 2003, and came
standard in Pub 2007. If you have the "Allow PNG..." option checked and do
not compress your graphics, Publisher will make multiple copies of images,
and frequently both .jpg and .png versions, or .gif and .png options. The
problem was that the oversize images would take forever to load, and with
multiple copies of your images, your overall file size was increased
substantially...or I should say the index_files folder was "heavier" and
larger with the increased number of image files within. So, I always
suggested unchecking the option of "Allow PNG...". The experiment I tried
was to create a word art similar to your Sponsors/Advertisers heading, and
checked the "Allow PNG...", Published to the Web and directed the output to
my hard drive, and opened the page with both IE6 and FF3.0, and the word art
was converted to a .png file instead of a .gif file, and the image looked
equally good in both IE and FF.

So, if you want to continue to use the word art headings, and want them to
look better in FF, check the option of "Allow PNG...". The only downside I
can see right now is that the png files are larger than the .gif files, and
thus will load slower. Also all the other images on the page that are
usually produced as gifs will also be converted to pngs, so your overall
file size and loading time for the page will be a bit slower. But as long as
you always compress the graphics before publishing, you might not notice
much difference in loading time. For what its worth, this is the first time
I have seen any advantage of using PNG files vs. GIF files, so thanks...you
taught me something else. However

Now as per you "wavy" text, anytime you see "wavy" text, think image. Image
representations of text will almost always be less clear and exact as would
text. Though the referenced paragraphs don't look that much different to my
eye, the "waviness" you are seeing is probably because the text with the
link is not a gif file, but the paragraph before and after it is:
http://www.nflaace.org/index_files/image645.gif .

I am not sure exactly what you are doing, but I don't think using a fill
color in the text box is necessarily the reason your text is being converted
into an image...at least not in all cases. If you try to left click, drag,
select text in the left column under Who We Are, then that text is text, and
hasn't been converted. And yet if you try to select the text under
Privacy/Legal it has been converted:
http://www.nflaace.org/index_files/image661.gif If you study that image you
will notice that the bar above the text and a gray bar to the left of the
text has been incorporated into the gif along with the text. Under Who We
Are, that text also has the gray bar to the left of the text, and yet it
isn't being converted. That leaves one design element that is different, and
that is the bar above the text. You have a bluish bar under the Who We Are,
but a black bar under Privacy/Legal...what did you do different? It may be a
spacing issue...perhaps nudge the text box below the bar under P/L down a
bit. Perhaps if you are overlaying it, try bringing forward? I don't know,
but if you can figure out why the text below Who We Are is not being
converted to an image, and the text below Privacy/Legal is, then perhaps you
will be able to fix the problem of the text being converted to an image
without resorting to the fill color text box behind a non-fill color box....

Ain't web design fun? <g>

DavidF


"Liz" <liz@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E5C1DC4F-1519-4A21-9D81-C83D66270553@xxxxxxxxxxxxxxxx
Hi, David,

Thanks for your reply, and your kind words. I've been helped with several
problems on this discussion board, and am glad to offer my experiences in
return.

On blocking:

There are several pages on which I regularly block and unblock several
elements so I can move structured sections around and add new info, or
descriptions of differing lengths. Especially true on pages like News,
Meetings and Employment. Less true on other pages with basic info that
changes only occasionally.

I currently use the "Shift + Select, then click the Group icon" system.
Will try your "left click and draw rectangle" system as well. May be
quicker.

Will also try your original version of the box-within-a-box color link
killer solution. Gives me a nice alternative.

On Firefox text problems:

On further analysis, I found the problem occurs mostly:

1) With autoform section headings. (See example "Book of the Month" on
home page, www.nflaace.org.)

These were created to give a consistent design element to the site. They
look fine in IE, but are faint, slightly blurred in Firefox. Would hate
to
replace with regular text headings, but will if I have to.

2) With some titles in italics, but not all.

Can try re-typing these.

3) In pre-formatted design elements containing text boxes, where the
"box-within-a-box" trick was performed.

See example on About Us page at www.nflaace.org. In the
Sponsors/Advertisers section top of column 2, the new box-in-a-box is
paragraph 2, the sentence containing a link. When I view in Firefox, the
original paragraphs 1 and 3 text appear fainter, less defined, "wavy."
The
new text inside the box-within-a-box (paragraph 2) appears clear and bold.
These design elements also help give the site consistency, and I don't
want
to lose or change them. May have to re-type all text within these
elements
in a larger new inner text box.

Maybe just my computer, but if that's the way it appears to you, then the
Firefox version of the site appears very "patchy," with some text showing
OK,
and some not.

Not sure any solution possible, but any advice appreciated as always.

Thanks.

Liz4.0


"DavidF" wrote:

Big cheer from me! Congrats...your site looks great.

Though it took you a lot of time and trial and error to fix your site, I
think you will find that revising or adding to it from this point won't
take
as long as you expect. Now that you know what you can't do design wise,
you
will build your new pages accordingly. Just part of the learning curve...

Grouping and ungrouping... Most of the time I find that once I get a page
built, I don't have to do that much editing on that page in the future,
so
ungrouping before publishing should not be much of a burden. If you do
need
to move a group of elements and want to regroup them, I assume that you
know
that you can hold down the shift key and click each element, and then
group
them all. Alternatively, you can sometimes just left click and "draw" a
rectangle around all the elements to select them all for grouping.

Congrats on figuring out the workaround for the fill color killing links
and
posting it. I have suggested a slightly different version before. Remove
the
fill color from your current text box. Then draw a new text box the size
of
your current text box, insert the fill, and move it so that it overlaps
the
original text box. If you have the Snap To options checked, then you can
just drag the sides to snap to the sides of the original text box. Then
using Arrange > Order > Send to the back. I don't know if this would be
easier for you or not.

As per your text looking different in FF than in IE, that is common. FF
renders text a little different than IE, and sometimes a bit different in
size. I wouldn't be too concerned about it, but if you will post a link
to
an example of your "wavy" text, I will take a look at it.

I would also like to thank you for taking the time to post your results
and
share with people how you fixed your issues and your workarounds. This
will
be helpful for others, and of course I am glad to hear of your success. I
always appreciate it when people post back.

DavidF


"Liz" <liz@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B140475C-A7A3-4C88-B9E6-DC5F91D56884@xxxxxxxxxxxxxxxx
Hello again,

Well, mission finally accomplished!

The good news is that by downloading Firefox, changing the design as
suggested, comparing the site in IE and Firefox for each step, plus a
good
deal of trial and error, I finally did produce a site that can be
viewed
and
used by IE, Firefox, and Mac users alike. My "Mac Site Tester" gave it
the
thumbs up, with all navigation, links and form working OK.

I knew that eventually I'd need to address the browser compatibility
issues,
but was fully occupied and sufficiently challenged just designing the
site
and keeping it updated.

However, Rob and David gave me the push I needed, plus the how-to's to
re-design the site and learn how to test it for more universal
compatibility
with other browsers. It wasn't easy, but I feel I've passed another
hurdle
on site design now. Forgive a small cheer at this point...!

The downside is that maintaining that level of compatibility will now
take
much more time and attention. Each small update will require several
more
steps, constant comparing in different browsers, etc. The price of
being
a
barely competent "webmaster," I guess.

I thought I'd help others in the same boat by detailing some solutions
and
work-arounds, and a possible problem I found:

1) David was right to say that in general, it was the grouping of
elements,
and background tints/fill in text boxes that caused most of the
compatibility
issues. Borders did play a part in a few cases, but were not always
the
culprits. We're mainly talking about areas with links, navigation, or
otherwise, and pages with forms.

2) I usually left some common design and text groupings left grouped
before
uploading, because they were easier to move around when updating or
adding
infomation. Now, it seems I have to ungroup them all before saving and
uploading. This means, of course, there's more time and work needed
for
the
next update, since I have to re-group those elements again before I can
move
them around, then un-group once again, etc. So be it, but I wish there
were
an easier way.

3) My goal in all of this was to keep close to the same general design
for
the site. Light background tints in some text boxes and navigation
bars
were
an important design element I was unwilling to lose.

But, I discovered a work-around. If you have a text box with a
background
tint that includes a link or form, first delete the tint or fill using
Format
Box. Then, select and cut a block of text containing the links. Next
create
a new text box within the current one, and paste the text back inside
the
new
text box. Re-size and re-position your new box as needed. Then, click
on
the outside or original box only, and using Format Box, re-click on
your
original background tint/fill.

What happens is that while the outside box has a tint/fill, the inside
box
with the links technically does not. When viewed in both IE and
Firefox,
however, both boxes show the tint or fill seamlessly. Because the
computer
thinks the inside box doesn't have a fill, the links contained therein
actually work in both browsers.

You end up with what looks more or less like your original tinted text
box,
but with live links in both browsers. On slow dial-up, that page may
download a tad slower, but on broadband, I'll bet you won't see the
difference.

4) The only possible problem remaining is how text looks in both IE
and
Firefox. My Mac Tester didn't see any problems visually, but when I
.

Relevant Pages

  • Re: Publisher 07 Form Wont Work With Mac
    ... The problem you are having with your section headings is that Publisher ... Ain't web design fun? ... look fine in IE, but are faint, slightly blurred in Firefox. ... steps, constant comparing in different browsers, etc. ...
    (microsoft.public.publisher.webdesign)
  • Re: How do I make a web page appear as large as screen when upload
    ... I used the 3 available layers in the design of the website cited above, ... doing avoid "ghosting" of the image in high resolution. ... Publisher allows one to create a decent webpage in far ... including graphics. ...
    (microsoft.public.publisher.webdesign)
  • Re: Is Publisher 2003 an effective way of creating and managing a
    ... changing Publisher or Word to produce more "compliant" code. ... you can get your design and layout to work in those two browsers, ... If you are willing to learn the basics about HTML coding and CSS, ... for years -- until Firefox came along. ...
    (microsoft.public.publisher.webdesign)
  • Re: Is Publisher 2003 an effective way of creating and managing a
    ... Why is it bad to use these programs to produce proprietary html code, ... for years -- until Firefox came along. ... Web designers of the world, who were expected to design separate sites ... Word and Publisher are primarily programs for print ...
    (microsoft.public.publisher.webdesign)
  • Re: MS Publisher Web Design
    ... If you have Firefox and IE you can see the difference ... > MS Publisher Web Designer ... >>> but not work well in other browsers. ... There are things you can do with your design that>>> will ...
    (microsoft.public.publisher.webdesign)