Open GoogleCodeExporter opened 8 years ago
Still not fixed in revision 829b7e7706. The dots are still descended on "i" and
"j",
and the line spacing is now unnaturally large as well.
Original comment by codeman38
on 27 May 2010 at 12:05
Thanks for checking that version. We have another version of the file from the
designer, but it has line spacing too small now. Hopefully we can get a fixed
version
soon.
Also, to clarify, this shows up as a problem on 10.6, but not 10.5, which is
where I
did most of my testing.
Original comment by r...@google.com
on 27 May 2010 at 4:02
Apple's font renderer is just weird. 10.6 also fills in the counters of some of
my
own fonts when 10.5 rendered them fine.
Original comment by codeman38
on 27 May 2010 at 4:03
Confirm that the 'dot accent' issue only showed up in OSX 10.6.x. The issue
seemed to
be caused by diacritics being referenced from other unicode slots, i.e.
lowecase i
referenced 'dotless i' (u+0131) + 'dot accent'(u+02d9). 10.6.x seemed to be
rendering
the 'dot accent' on the baseline as it appears in u+02d9 instead of above the
'i'
stem or 'j' stem. Same was happening in other diacritic chars. Issue was
resolved by
generating font files from FontForge with no referenced unicode slots. Also i
*think*
that 10.6.x has an issue with some .woff files converted from truetype.
Converting
with sfnt2woff.exe seemed to kill off any diacritic issues in woffs in 10.6.x.
Need
to test the effects of different converters on this issue.
First image is Safari 4.0 on OSX 10.6 showing diacritics issue. 2nd image shows
same
after fix. Will do some tests to nail more specifics on this
Original comment by vernnobile
on 1 Jun 2010 at 8:23
Attachments:
Incidentally, I discovered that generating the fonts as OpenType CFF rather than
TrueType in FontForge fixed the diacritic issues as well. But then you'll run
into
hinting issues on Windows and Unix...
Original comment by codeman38
on 1 Jun 2010 at 8:31
Hopefully the newest version fixes the problems. It was made by breaking the
references, which should be robust
but does mean the file is a bit bigger than it should be. We'll keep looking
into it and see if we can make a fixed
version. For now, we're shipping only TT files (rather than OT CFF) so that we
can avoid the problems of
inconsistency from having two different formats, but if we find that CFF
consistently works better on some
platforms (Mac and potentially IE9) maybe we'll reconsider.
Original comment by r...@google.com
on 5 Jun 2010 at 12:57
Now another bug's been introduced -- the "fontname" field for Nobile, Nobile
Bold,
and Nobile Bold Italic should be distinct in each font, but they're not. OS X
recognizes all three of those styles as the same font as a result.
Original comment by codeman38
on 5 Jun 2010 at 5:30
Here's an updated version of the TTFs in which I fixed the style names so that
the
fonts were grouped under the same family and none of the styles clash with one
another name-wise. Let me know if these look good on your end.
Original comment by codeman38
on 6 Jun 2010 at 3:20
Attachments:
And here are SFDs with the same updates. I'd just check these into the Mercurial
repo, except I don't have permissions to update it. :)
Original comment by codeman38
on 6 Jun 2010 at 3:26
Attachments:
When using the default settings with only firebug add-on
installed on firefox 4.0 on a
OSX 10.6.6 Nobile is displayed as 'bold italic' when the css is
body {font:14px/1.5em Nobile, georgia, sherif;}
Opera 10, Safari 5, Chrome 10, all display properly with no problems (I
haven't yet tested IE)
Loks kinda like firefox is to blame...
Does any one know any work arounds?
Original comment by greenzt...@gmail.com
on 28 Mar 2011 at 3:19
Original comment by pathum...@gmail.com
on 28 Sep 2014 at 4:38
Original issue reported on code.google.com by
codeman38
on 22 May 2010 at 12:31Attachments: