I’ve created graphics items with no background to use as rollover items, but the text is not rendering very well in browsers. (looks fine in FW)
Text used - Arial 14pt for the Black 16pt for the Cyan
Everything else is set to defaults.
Oddly the top links don’t look too horrible, but the identical technique was used on the graphic/text rollovers at the bottom of the page and they look much worse - very ragged.
At least I’ve got internal navigation working…LOL.
Speaking of browsers, for fun I tried Netscape Navigator 4.77 on OS9 - SPLAT - what a mess, but we can assume most folks will have more modern browsers in use today…
I did notice in FF, IE, OP html text tends to render slight bigger than what is shown in the FW workspace…it made my gibberish text run out of the boxes in some cases… (I’m sure there is a “force to fit” option somewhere: just haven’t found it yet).
If I create a text block in 14 pt Arial and create it as GIF text it
looks fine.
If I create a block of HTML text and then convert the box to a
graphic as JPEG it does looks more ragged/artifacted.
Can’t get it to look as rough as yours though. Have you checked the
anti-aliasing setting in Preferences>Text
Cheers
Pete
On 18 Jan 2008, at 23:07, igirl wrote:
I’ve created graphics items with no background to use as rollover
items, but the text is not rendering very well in browsers. (looks
fine in FW)
Text used - Arial 14pt for the Black 16pt for the Cyan
Everything else is set to defaults.
Oddly the top links don’t look too horrible, but the identical
technique was used on the graphic/text rollovers at the bottom of
the page and they look much worse - very ragged.
At least I’ve got internal navigation working…LOL.
Speaking of browsers, for fun I tried Netscape Navigator 4.77 on
OS9 - SPLAT - what a mess, but we can assume most folks
will have more modern browsers in use today…
I did notice in FF, IE, OP html text tends to render slight bigger
than what is shown in the FW workspace…it made my gibberish text
run out of the boxes in some cases… (I’m sure there is a “force
to fit” option somewhere: just haven’t found it yet).
These were not HTML to GIF conversions…they started as graphics boxes and stayed that way.
The graphics item box is made @ default settings…anti-alias AUTO - no background
Double click to turn it to text, type, highlight the word, make Arial, Bold, Center
Make another right under it using duplicate/offset 200px vertical - change the text to color #2 for rollover - align, group etc…
I wonder if the quality would somehow degrade due to using duplicate?
Once I got going I used it a lot as I had 24 versions of the same graphic/text box basically (12 rollovers)
(Paste one aligned in the #1 position, then duplicate 5 more horizontally 120px apart from each other, perfectly set up).
The title and tag line were done exactly the same way - graphic box w/text and they look perfect!??!
I would be tempted to alter the anti alias setting away from Auto.
Because you have graduated backgrounds this could be causing the problem.
Try using a colour in your anti alias that is as close to the background as possible.
Sometime around 19/1/08 (at 00:09 +0000) Pete MacKenzie said:
If I create a text block in 14 pt Arial and create it as GIF text it
looks fine.
If I create a block of HTML text and then convert the box to a
graphic as JPEG it does looks more ragged/artifacted.
Just in case someone misunderstands what you’re saying here… This
isn’t because you started with the item as an HTML box - it is purely
because the JPEG format is not well suited to high-contrast graphics
such as type.
Can’t get it to look as rough as yours though. Have you checked the
anti-aliasing setting in Preferences>Text
Those bits of graphic type that are shown in the original poster’s
URL are being antialiased to a darker blue than is actually behind
most of the type.
Yes, antialiasing is the problem, but DON’T try to change it
globally! Change it object-by-object, so you don’t affect the way
anything else antialiases. Freeway’s default of Auto is pretty damn
near perfect 99% of the time.
Setting the type’s antialias colour to something a little lighter,
perhaps the shade in the gradient that lies midway through the
letters, should provide a good compromise.
Alternatively, combining the type graphics with an instance of that
gradient put into a graphic box should sort it out.
Those bits of graphic type that are shown in the original poster’s
URL are being antialiased to a darker blue than is actually behind
most of the type.
Yes, what you saw is the “improved” version - with Auto AA turned off and set to custom…(darker blue) With Auto turned ON it was really bad.
Yes, antialiasing is the problem, but DON’T try to change it
globally! Change it object-by-object, so you don’t affect the way
anything else antialiases.
Exactly how I did it - just the bits that needed fixing…
That only makes sense!
Setting the type’s antialias colour to something a little lighter,
perhaps the shade in the gradient that lies midway through the
letters, should provide a good compromise.
Still experimenting with the best fit for this…dying for an eyedropper tool here that could grab the color from the doc!
Alternatively, combining the type graphics with an instance of that
gradient put into a graphic box should sort it out.
Now that’s a thought! Would grouping them, and checking “combine graphics” simply make them play better together?
Would it break the rollover and/or require rebuilding?
Sometime around 19/1/08 (at 00:09 +0000) Pete MacKenzie said:
If I create a text block in 14 pt Arial and create it as GIF text it
looks fine.
If I create a block of HTML text and then convert the box to a
graphic as JPEG it does looks more ragged/artifacted.
Just in case someone misunderstands what you’re saying here… This
isn’t because you started with the item as an HTML box - it is purely
because the JPEG format is not well suited to high-contrast graphics
such as type.
Absolutely. Well clarified
Can’t get it to look as rough as yours though. Have you checked the
anti-aliasing setting in Preferences>Text
Those bits of graphic type that are shown in the original poster’s
URL are being antialiased to a darker blue than is actually behind
most of the type.
Yes, antialiasing is the problem, but DON’T try to change it
globally! Change it object-by-object, so you don’t affect the way
anything else antialiases. Freeway’s default of Auto is pretty damn
near perfect 99% of the time.
Sure - I suggested looking in case it was turned off - it was late
though so I wasn’t v rigourous in my thinking/explaining. must do
better…
You have it - in the bottom right hand corner of the Freeway colour picker is a link to the Apple one. That one has an eyedropper.
Thanks Paul, but I can’t find any eyedropper here - the choices in the Anti-alias picker are limited to hex colors I believe unless I’m really missing something?
Thanks Paul, but I can’t find any eyedropper here - the choices in
the Anti-alias picker are limited to hex colors I believe unless
I’m really missing something?
If you just click on the magnifying glass, which is the ‘eyedropper’,
you can pick your anti-alias colour from anywhere, as far as I
remember …
Sometime around 19/1/08 (at 13:07 -0500) igirl said:
dying for an eyedropper tool here that could grab the color from the doc!
Try this:
Make a new colour, then click the small colour wheel at the
lower-right of Freeway’s Color dialog. This opens the standard Apple
‘Colors’ window. Now click the small magnifying glass icon… this is
a colour sampler tool that lets you pick up the colour from anything that’s on your screen.
Would grouping them, and checking “combine graphics” simply make
them play better together?
Maybe…
Would it break the rollover and/or require rebuilding?
Got it - how silly of me- I was looking for an actual eyedropper tool (found standard in almost every graphics app) It was disguised as a magnifying glass! LOL
Keith,
I can’t believe that, after many years of using Apple apps, I did not know that the magnifying glass icon was a sampler. I have been using a separate app for that function. Thanks for the great hint and time saver.
Sometime around 19/1/08 (at 14:41 -0500) igirl said:
I was looking for an actual eyedropper tool (found standard in
almost every graphics app) It was disguised as a magnifying glass!
LOL
Outside of paint environments, the eyedropper tool is not that
common. The magnifying glass as a colour sampler won’t make much
sense to those already used to the pipette UI ‘conceit’, but it has
the advantage of magnifying what you point at to make pinpoint
sampling easier. The pros and cons of a particular interface element.
(Nobody speak to me about Word’s ‘Format Painter’ paintbrush tool!
That program is such a collection of user interface design
abominations…)
