Posted: Sat Jan 31, 2004 8:16 am Post subject: Symbol and Zapf Dingbat Fonts
asxless, your postings on OOo 1.0.3 font issues enabled me to get Symbol and Zapf Dingbat working there. Thank you very much!!
In NeoOffice/J the Symbol, OpenSymbol and Zapf Dingbat fonts give me the dreaded empty rectangle. This happens in both my "personal" and "work" OS X accounts.
When I first tried NeoOffice/J I'm sure Symbol (or OpenSymbol?) worked. I think (but can't be sure) the Symbol and Zapf Dingbat font problem began (or OpenSymbol quit working) when I upgraded to NeoOffice/J .71. Due to multi-user problems I experienced with OOo 1.0.3 I switched back and forth between OOo 1.0.3 and NeoOffice/J quite a bit since late December. I was struggling to get to a stable font configuration and resolve my multi-user trouble at the same time, so I can't remember exactly what went on.
I also know my Os X 10.2.8 font libraries are far from their shipment state due to many attemps to get things going in OOo 1.0.3. Since I can now get my work (which requires Symbol) done in OOo 1.0.3, I am reluctant to mess with my fonts in any way.
I use .80 in my personal OSX account for everything. I will use it in both accounts when the Symbol - Zapf Dingbat mystery is resolved.
I am very greatful to have NeoOffice/j .80.
Bill _________________ G4 Powerbook 1.33 GHz
OSX 10.3.6
How did you get OpenSymbol and ZapfDingbats to work in OOo X11? I am curious because maybe that has caused the NeoJ's OpenSymbol font and Mac OS X's built-in ZapfDingbats font to become disabled.
Also, are OpenSymbol and ZapfDingbats working in the TextEdit application?
How did you get OpenSymbol and ZapfDingbats to work in OOo X11? I am curious because maybe that has caused the NeoJ's OpenSymbol font and Mac OS X's built-in ZapfDingbats font to become disabled.
Also, are OpenSymbol and ZapfDingbats working in the TextEdit application?
Patrick
Patrick,
I suspect he followed my post on OOoDocs in the sticky thread titled "Font fixes for OOov1.0.3 GM" Essentially it tells people how they can get Symbol to work in OOo X11 by making sure OOo X11 only sees one version of Symbol -- the one in the X11 bit map fonts directory. The other parts of that post explain how to get OOo to anti alias other common fonts (e.g. Helvetica, Times etc.) by doing the opposite -- making sure OOo can NOT see the X11 bit map version of those fonts. BTW this includes Zapf Dingbats. In both cases the 'tricks' are
1- which X11 bitmap fonts you hide or expose and
2- which OS X fonts you convert and install (or don't) in the OOo share/fonts directories.
They do not involve ANY changes to the fonts in any OS X font directories.
If I understand how NeoJ works, it only sees the fonts in the OS X directories (and your soft linked fonts in the NeoJ/share/fonts directories). So fixing the fonts in OOo X11 _should not_ effect NeoJ but...
You are definitely on to something with your query about whether Symbol and Zapf Dingbats work in Text Edit. I just checked and they DO NOT work in TextEdit or OmniOutliner:( But they DO work correctly in Word, Excel, PowerPoint, BBEdit Lite. Interestingly, the former are Cocoa and the later Carbon. BTW After selecting Symbol in TextEdit or OmniOutliner the Show Fonts dialog shows that a completely different font was actually selected (e.g. Times) -- DUH. FWIW I hadn't noticed this OS X glitch because I never use TextEdit (or OmniOutliner) for complex documents.
Edit: And it gets worse:( Over a half dozen fonts don't work correctly with TextEdit -- Symbol, Zapf Dingbats, Monotype Sorts, Webdings, Wingdings, Wingdigs 2, Wingdings 3, and few other 'specialty fonts'. In each case selecting a text fragment then selecting the problem font in the Show Font dialog immediately jumps to a completely different (but usually the same) font. But reselecting the font, simply highlights the font selected even though it is NOT to font being used to render the text.
Edit 2: Believe it or not, the behavior described above is NOT a bug -- it is how OS X Cocoa apps are _designed_ to work with specialty fonts like Symbol and Zapf Dingbats. And NeoJ has simply inherited this behavior as a native OS X app. If you already know how to input and format special characters (e,g, Symbol and Zapf Dingbats) in OS X Cocoa apps you can stop here and use that technique in NeoJ. The rest of you should read on. Note: you can skip most of my posts in this thread which simply chronicle my personal and painfully public, path to OS X Cocoa font implementation enlightenment.
-- asxless
Last edited by asxless on Mon Feb 02, 2004 8:23 am; edited 1 time in total
'Disabling' _all_ of the Fonts in...
-- /OS9System/Fonts
-- /Library/Fonts (except Arial*)
-- ~/Library/Fonts
... still produces the identical problems with Symbol and Zapf Dingbats when selected in Cocoa apps (e.g. TextEdit, OmniOutliner, etc.). Even after a full shut down and power up, selecting a text fragment then selecting either Symbol or Zapf Dinbats causes the Show Fonts dialog to jump to a different font (e.g. Times) instead of honoring the user input. Note it does _not_ simply leave the previous font selection in place. It actually changes the font selection to a different but incorrect font.
* I left Arial enabled because I have it set as the default font. BTW TextEdit simply crashes and OminOutliner throws up an error dialog if they can't find it. In both cases you have to figure out what went wrong the hard way. Isn't that handy;)
And for the record, I have not found a single Carbon application that has _any_ problems with the Symbol or Zapf Dingbats fonts.
FWIW I am running 10.2.6 and removed the .dfont version of Helvetica (that normally resides in the /System/Fonts directory) over a year ago. This allows me to use the Type 1 version of Helvetica for compatibility with commercial printers, etc.
Joined: May 31, 2003 Posts: 219 Location: French Alps
Posted: Sun Feb 01, 2004 10:10 am Post subject: Just to clarify
So it looks like this font problem is not Neo/J, nor even standard Jaguar ?
I'm now running 10.3.2 so I can't check it again, but I'm pretty sure that Zaps Dingbats worked in Textedit, as it does under Panther (checked).
Notice anyway that, while rendering correclty in a Neo/J document, Dingbats font displays as square in the font list menu, if this one is rendered.
Posted: Sun Feb 01, 2004 2:42 pm Post subject: Re: Just to clarify
Max_Barel wrote:
So it looks like this font problem is not Neo/J, nor even standard Jaguar ?
I'm now running 10.3.2 so I can't check it again, but I'm pretty sure that Zaps Dingbats worked in Textedit, as it does under Panther (checked).
Notice anyway that, while rendering correclty in a Neo/J document, Dingbats font displays as square in the font list menu, if this one is rendered.
Thanks for the feedback Max.
I agree that "it looks like this font problem is not Neo/J" but...
I think it may be a general Jaguar problem. I just did a 'ground level' install of Jaguar (10.2.1) in an empty partition of an external firewire drive. When I opened TextEdit and ran the previous test --- I got _identical_ incorrect results:(
It would be interesting to see if anyone running Jaguar has gotten Symbol and Zapf Dingbats to work in a Cocoa app or NeoJ -- and how they did it:)
FWIW, I use 10.2.8 with all of the latest system updates as my primary development machine.
It would interesting see if installing of the system updates makes this problem go away. If it does, I can add a check to the installer for future releases.
Joined: May 31, 2003 Posts: 219 Location: French Alps
Posted: Sun Feb 01, 2004 3:37 pm Post subject: international settings?
Quote:
It would interesting see if installing of the system updates makes this problem go away. If it does, I can add a check to the installer for future releases.
If it does not, could this problem be related to some international setting, changing the default system font and unicode handling? I'm thinking of keyboards available in the menu, and such.
FWIW, I use 10.2.8 with all of the latest system updates as my primary development machine.
It would interesting see if installing of the system updates makes this problem go away. If it does, I can add a check to the installer for future releases.
Patrick
That is interesting. At least there's hope:)
But, as it happens, I just applied the 10.2.8 Combo and all* of the other updates offered by Software Update in the first go, and... the problem remains in TextEdit:(
I downloaded the next batch of Updates to disk (e.g. Java 1.4.1, QuickTime 6.5 and several security updates). I'll be applying them manually one at a time to see if (hopefully when) anything changes .
But first I'm going to install NeoJ 0.8 to confirm that it too has the problem. Frankly I don't care if TextEdit displays Symbol or Zapf Dingbats. But I really want NeoJ to.
-- asxless
* well not exactly "all" I skipped the large iMovie update since this is just a test install and I don't plan on editing videos while debugging fonts:)
Posted: Sun Feb 01, 2004 5:59 pm Post subject: Re: international settings?
Max_Barel wrote:
If it does not, could this problem be related to some international setting, changing the default system font and unicode handling? I'm thinking of keyboards available in the menu, and such.
Max
Hi, I'm new here, but because of my work I try to keep an eye on intl/multilingual issues
IIRC, back in 9 or 9.1, whenever Apple started its Unicode support, those fonts started requiring separate kybds (since those characters were really Unicode blocks), and I believe this was the case up through 10.2. I read something about 10.3 changing that, and I no longer have those kybds in 10.3.2.
However, I'm unable to make Zapf Dingbats or Symbol appear in Cocoa apps by typing using any kybd (script Roman or Unicode) other than Unicode Hex Input (and cannot select those fonts otherwise).
In NeoJ 0.7.1--hope to get 0.8 tomorrow-- I get boxes when typing in those fonts, except when inserting characters by using the [OS's] Character Palette. (I have no access to any of the kybds that are script "Unicode" in NeoJ.)
I take this to mean 1) Apple didn't make the change at all and deleted the special kybd layouts or 2) Apple made the change and didn't update TextTedit or 3) something's wrong with my system.
Or 4, maybe I've misunderstood this entire thread.
Last edited by sardisson on Sun Feb 01, 2004 11:48 pm; edited 1 time in total
Joined: May 31, 2003 Posts: 219 Location: French Alps
Posted: Sun Feb 01, 2004 6:54 pm Post subject: Re: international settings?
sardisson wrote:
However, I'm unable to make Zapf Dingbats or Symbol appear in Cocoa apps by typing using any kybd (script Roman or Unicode) other than Unicode Hex Input (and cannot select those fonts otherwise).
In NeoJ 0.7.1--hope to get 0.8 tomorrow-- I get boxes when typing in those fonts, except when inserting characters by using the character palette. (I have no access to any of the kybds that are script "Unicode" in NeoJ.)
Should I precise, I think I should, that I do use the character palette to insert Zapf Dingbats characters.
If Dingbats and symbols are now coded in unicode, their codes should be differents than any other normal characters and I don't see how one could type any of them from the keyboard, beside using a special one.
It's documented in the Help that using the palette is the way to insert Zapf Dingbats chars even when an application is not able to use the Zapf Dingbats font from the keyboard.
BTW, I don't know how to use the "unicode hex input" keyboard.
Posted: Sun Feb 01, 2004 8:57 pm Post subject: Re: international settings?
Max_Barel wrote:
Should I [be] precise, I think I should, that I do use the character palette to insert Zapf Dingbats characters.
If Dingbats and symbols are now coded in unicode, their codes should be differents than any other normal characters and I don't see how one could type any of them from the keyboard, beside using a special one.
It's documented in the Help that using the palette is the way to insert Zapf Dingbats chars even when an application is not able to use the Zapf Dingbats font from the keyboard.
BTW, I don't know how to use the "unicode hex input" keyboard.
Max,
Thanks for being 'precise'. Yes I too can scrounge away in the NeoJ Special Character palate and find the characters I want in both Symbol and Zapf Dingbats.
But that is not what I have to do in OOo v1.0.3 (X11) or Office:mac or any carbon application in OS X (Jaguar). I can simply type many of the font's characters directly from the keyboard and get even more of them when using the shift and/or option keys. Furthermore font names for Symbol and Zapf Dingbats appear as legible glyhs in OOo v1.0.3 (x11) font menus (not empty boxes). In OOo v1.0.3 (x11) and OS X carbon apps I can select almost any text (e.g. abcdefg) and then select Symbol or Zapf Dingbats from the font menu and see readable glyphs of greek letters or some dingbats (not empty boxes). That was my expectation for NeoJ and why I posted that I did not think NeoJ 0.8 was working correctly for me.
Posted: Sun Feb 01, 2004 9:27 pm Post subject: Re: international settings?
Max_Barel wrote:
BTW, I don't know how to use the "unicode hex input" keyboard.
Hold down option and enter the 4 character hex code for the glyph [opt 2701 gives the downward- pointing cutting scissor]. It's only easier than the character palette if you have the hex codes memorized This kybd first arrived in 9.x where there was no character palette.
Posted: Sun Feb 01, 2004 9:29 pm Post subject: Re: international settings?
sardisson wrote:
Hi, I'm new here, but because of my work I try to keep an eye on intl/multilingual issues :-)
IIRC, back in 9 or 9.1, whenever Apple started its Unicode support, those fonts started requiring separate kybds (since those characters were really Unicode blocks), and I believe this was the case up through 10.2. I read something about 10.3 changing that, and I no longer have those kybds in 10.3.2.
However, I'm unable to make Zapf Dingbats or Symbol appear in Cocoa apps by typing using any kybd (script Roman or Unicode) other than Unicode Hex Input (and cannot select those fonts otherwise).
In NeoJ 0.7.1--hope to get 0.8 tomorrow-- I get boxes when typing in those fonts, except when inserting characters by using the character palette. (I have no access to any of the kybds that are script "Unicode" in NeoJ.)
I take this to mean 1) Apple didn't make the change at all and deleted the special kybd layouts or 2) Apple made the change and didn't update TextTedit or 3) something's wrong with my system.
Or 4, maybe I've misunderstood this entire thread.
Thank you for your insight into this little duality of OSX. It took awhile for your post to make sense to me. You certainly did not misunderstand this thread. In fact you may have been the only one who understood it well enough to recognize the miscommunication.
After looking at my apps I now realized that almost all of them (and all of the ones I use for anything serious) are carbon or X11. So I had never stumbled on to the idiocy of having the very same font interpreted and input in two entirely different ways within the same OS depending on whether it was 'Cocoa' or 'Carbon'. Worse yet that an OS X user has to manually change the _International_ Input Menu Character Palate in order to insert a gylph representing an arrow (or a star, etc) but only if the application happens to have been coded using the Cocoa frameworks -- DUH. So much for Apple's famed 'ease of use' and 'intuitiveness of the user input/interface'.
Joined: May 31, 2003 Posts: 219 Location: French Alps
Posted: Sun Feb 01, 2004 9:55 pm Post subject:
Quote:
Thanks for being 'precise'. Yes I too can scrounge away in the NeoJ Special Character palate and find the characters I want in both Symbol and Zapf Dingbats.
Sorry for the french idiomatic verb.
Futhermore, what I intended to pinpoint is that I use the OS X palette, not the Neo/J one. The native palette you find in the Apple menu from the menu bar, and only if you have the option checked in the International preference panel.
So it turn out that no Cocoa app' behave as you expect, since there is no mapping between normal fonts and dingbats. In my opinion this is a correct behaviour. Then the lack for a special kybd for symbols. Carbon apps behave the old way. The funny ? point is that Neo/J use Java 1.3 which, in turn, is said to use Carbon and 1.4 Cocoa
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
