Ask a Question related to Macromedia Contribute General Discussion, Design and Development.
-
laurence #1
fonts too small editing on Mac
I have a site built using Dreamweaver templates with pages edited in
Contribute. Layout is CSS-driven. Pages render correctly in Windows (IE6,
Firefox 1.5) and Mac (Safari 1.0+, Firefox 1.5, Camino 1.0+) web browsers, and
look OK in Dreamweaver (v.8) Design View and in Contribute 3.11 in Windows.
When editing using Windows Contribute 3.11, page layouts degrade a bit in the
usual way, but all editable text is legible.
Problem: when Contribute 3.11 on a Mac is used to edit the same pages, the
text is too small to read. It jumps from 11-12 pixels tall when viewing the
page down to 6 pixels when I click into "Edit Page".
Has anyone else seen this? Better, has anyone a workaround or solution?
The Mac runs MacOS X 10.3.9 "Panther"; would upgrading to "Tiger" maybe help
the font issue? (I see Tiger + Contribute has its own problems in these forums
with crashes, etc.)
-- Lars
laurence Guest
-
Very small fonts in Contribute
I'll create a page in Contribute & choose a font size - looks fine in the contribute application, but when published, all the fonts are reduced to a... -
Illustrator 10 isn't recognizing fonts that I've dropped in the Fonts folder
I'm confused about why my Illustrator 10 (running on OS 10) is only recognizing a subset of the fonts I have loaded into my Library/Fonts folder. Can... -
Extremely Small Fonts/Lines
My PS used to work fine but one time I must have copied and pasted something and all of a sudden the text size and lines are too small to see even... -
small fonts
Hello guys, since a have Director MX, I have extreme small fonts in my menu's? I'm not able to change this with windows-proporties. Does someone... -
Importing Small Fonts?
Hi, Thanks so much for any help. I read in the "Playing With Fire Book" that there are places online where you can get smaller fonts that would be... -
Arun Kumar M #2
Re: fonts too small editing on Mac
laurence wrote:
Hi,> I have a site built using Dreamweaver templates with pages edited in
> Contribute. Layout is CSS-driven. Pages render correctly in Windows (IE6,
> Firefox 1.5) and Mac (Safari 1.0+, Firefox 1.5, Camino 1.0+) web browsers, and
> look OK in Dreamweaver (v.8) Design View and in Contribute 3.11 in Windows.
>
> When editing using Windows Contribute 3.11, page layouts degrade a bit in the
> usual way, but all editable text is legible.
>
> Problem: when Contribute 3.11 on a Mac is used to edit the same pages, the
> text is too small to read. It jumps from 11-12 pixels tall when viewing the
> page down to 6 pixels when I click into "Edit Page".
>
> Has anyone else seen this? Better, has anyone a workaround or solution?
>
> The Mac runs MacOS X 10.3.9 "Panther"; would upgrading to "Tiger" maybe help
> the font issue? (I see Tiger + Contribute has its own problems in these forums
> with crashes, etc.)
>
> -- Lars
>
Looks like a strange behavior, Can you throw me your website URL. I have
never encountered this kind of problems, is it because of the styles
that are rendered in edit mode are picked up from the different css file?
Thanks
Arun
Arun Kumar M Guest
-
laurence #3
Re: fonts too small editing on Mac
[Q]Hi,
Looks like a strange behavior, Can you throw me your website URL. I have
never encountered this kind of problems, is it because of the styles
that are rendered in edit mode are picked up from the different css file?
Thanks
Arun
[/Q]
Hi, Arun. Sorry, no I can't give you a URL -- the dev site is not public.
The styles are correctly loaded by Contribute: I can tell because the CSS
includes positioning and layout, which is applied in Contribute's Edit Page
view.
Each layout's HEAD element is as follows (minus some unimportant details):
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<!-- InstanceBeginEditable name="HeadTitleRegion" -->
<title>MySite - MyTitle</title>
<!-- InstanceEndEditable -->
<meta name="description" content="words" />
<meta name="keywords" content="word,thing" />
<meta name="MSSmartTagsPreventParsing" content="true" />
<link rel="stylesheet" type="text/css" href="../../css/glbBasic.css" />
<style type="text/css" media="screen">
@import url(../../css/glbFormatting.css);
@import url(../../css/forms.css);
@import url(../../css/glbLayoutContent.css);
@import url(../../css/glbLayoutNav.css);
</style>
<link href="../../css/glbPrint.css" rel="stylesheet" type="text/css" title=""
media="print" />
<script src="../../js/global.js" type="text/javascript"></script>
<!-- SWFObject embed by Geoff Stearns [email]geoff@deconcept.com[/email]
[url]http://blog.deconcept.com/swfobject/[/url] -->
<script type="text/javascript" src="../../js/swfobject.js"></script>
<!-- InstanceParam name="OptionalBreadcrumb" type="boolean" value="false" -->
</head>
The good news is, I have a workaround: between the javascript tag and the
InstanceParam comment, I inserted the following:
<cfsetting enablecfoutputonly="yes" /><!---
*** NOTE: this hack is required for Contribute 3 on MacOS X.
Without it, the fonts in "Edit Page" view display too tiny to read.
The CFSETTING prevents the hack from being visible to browsers.
---><style type="text/css">
<!--
body,td,th {
font-size: 11px;
}
-->
</style><cfsetting enablecfoutputonly="no" />
When the page is served, the hack does not appear; in Contribute's Edit,
however, the <cfsetting> tags are ignored, the hack takes effect, and
Contribute shows text approx the same size as in its Browse window. (The hack
isn't necessary in Windows Contribute, but does no harm.)
How font sizes are defined in the included CSS:
I speculate that the Contribute rendering engine on MacOS X is unhappy with
relative font sizes. As best practise, our CSS specifies base font size in
percent, then all sizes in em units relative to that. (That way, IE and
Mozilla-based browsers, Safari et al can size fonts up/down for legibility; IE,
of course, will not resize fonts specified in px.)
So in the styles loaded above, I have:
===== glbBasic.css =====
body {
background-color: #fff;
font: normal normal normal small Verdana,Arial,Helvetica,sans-serif;
...
}
body, h1, h2, h3, h4, h5, h6, ol, ul, li, p {
color : #000;
font-family: Verdana, Arial, Helvetica, sans-serif; /* needs to be redefined
here for older browsers */
}
...
p, ul, ol, li { line-height: 100%; }
big { font-size: 110%; }
strong, b { font-weight: bold; }
/* sample header sizes, customize for each project
here if normal is 11pt, h1 is 24pt and h3 is 18pt
*/
h1 { font-size: 218%; }
...
h3 { font-size: 164%; }
...
===== end =====
===== glbFormatting.css =====
body {
background-color: white;
color: #333;
font-size: 69%; /* tested sizes are 60%, 62.5%, 69%, 76%. Anything else
requires testing (espcially on a Mac) */
}
p, ol, li, dd, table {
font-size: 1em; /* this should stay as 1em. anything else will lead to
potential problems with nested elements. Adjust font size in the body tag, or
define a class for exceptions */
...
}
...
===== end =====
So as interpreted by modern browsers, the base size for all fonts -- 69% --
seems to correspond to 11px text in a browser's default view. H1 tags are sized
to 218% times as large, corresponding to 24px in a default view. When the user
selects View > Text Size > Larger in IE, or uses the View > Text Size >
Increase control in Firefox, all the fonts are resized in proportion and Life
Is Good for folks who like bigger text (like me, at the end of a long day).
Anyway, thanks for your interest, Arun. I'll be interested to see what comes
of it.
-- Laurence
laurence Guest



Reply With Quote

