Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: How to specify font-path
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to specify font-path

MacFirst <email@hidden> wrote:

>Because it's important that each user see the same thing on their screen.
>Because when user-1 drags a rectangle from x,y to x',y', it's important that
>the words he sees himself drag-selecting be the same words that user-2 sees
>the drag-select rectangle enclosing.

Text-selection can be defined in terms of the text that's being selected.
It doesn't HAVE to be in terms of XY coordinates. Sounds like a design
problem to me.


>And, as much as I'd love to completely re-architect an already-working app
>to account for the differences in cross-platform font display, what I'd
>prefer to do is to eliminate those differences.

I may prefer that square pegs fit into round holes, but if I don't have a
wood-lathe handy, I may be forced to do a lot of hand-planing and sandpaper
work.

Still sounds like a design problem to me. Specifically, one based on a
faulty assumption: fonts don't vary.


>Several reasons -- one is difficulties with Font Metrics in a headless app.
>But you suggest I learn more about that, so I'll do so before grumbling
>about it (previous versions of the Mac JVM would fail if you so much as
>instantiated a Rectangle in a headless app, let alone anything so fancy as a
>FontMetrics object. Perhaps it's better, now.)

Previous versions of Java, i.e. before 1.4, didn't support headless operation.

Also, there are bugs in Apple's headless operation on their first 1.4.1
release. Some of these were fixed in 1.4.1U1. See the 1.4.1U1 release
notes.


>Another is that my particular application does not lend itself to different
>viewers (clients) seeing different views. So, while my server needs to do
>font metric calculations in order to know things like "this particular word
>doesn't fit in this particular rectangle", I also have the constraint of
>needing to keep the server and all the clients in-sync, in this regard.
>Having the server determine "this word fits in this small space", and the
>client ending-up clipping it is A Bad Thing for me. Hence, server and all
>clients on all platforms need to be thinking in terms of the same font.
>Hence my idea to just ship the font with the client.
>[...]
>And I *STILL* have to solve the "same image for both clients" problem, which
>I believe means I need to force the font.
>[...]
>But I'm still left with the "same image" problem...

You could distribute the centrally rendered image to the clients. A
delta-frame approach would work. That is, distribute only the changes, but
periodically send a new complete image. If the fundamental premise is
"same image", you should have distributed that, rather than letting each
client render its own image in its own form.


>> "Headless" doesn't mean "awtless". "Headless" just means there isn't a
>> user interacting graphically.
>
>While this is SUPPOSED to be the case, this was broken as recently as 1.3.1.
>While I will check into it for 1.4, it'd be nice to have a solution that
>works further back.

T'aint one. At least not for completely headless operation.

The best you might do is GUI-less, which can be obtained on Mac OS X with
the LSUIElement=1 key/value pair in "Info.plist". Search ADC for
"LSUIElement".

This will prevent the app from appearing in the Dock, and from presenting a
menu-bar. You can still show a Frame if you like, and bring it to front,
but it won't have a menu-bar. Of course, if you never show a Frame or
Dialog, then the user's perception is of a completely background
non-interactive application. Call it pseudo-headless.


>I understand that I want to instantiate a Font object, what I'm not clear on
>is how I specify that:
>
> Font thatFont = new Font ("MyFont", Font.PLAIN, 12);
>
>should look for "MyFont" in the app's .jar file (or a separate one, I'm not
>that way), rather than in the system font path.

AFAIK, Java does not offer that capability. Fonts and font-management are
platform-dependent.

I suppose you could load a PostScript font-file directly, then render the
glyphs yourself, and sidestep the whole Font question. The java.awt.font
package has some intriguing class and interface names:
GlyphMetrics
GlyphVector
OpenType
MultipleMaster

Or you could distribute a specific PS font (or TT font) file with your
application, and install it when the user installs the application. As
long as the font-name was uniquely identifiable, you'd have reasonable
expectation of getting what you ask for. Then you could check a returned
FontMetrics against the metrics values you require, and complain if they
don't match. In short, hard-wire to specific pre-determined metrics
values.

I don't think it's that hard to patch a PS font file to have a different
font name. I don't know about TT font files. If that's the route you
take, you should probably read the PostScript and TrueType/OpenType
font-file format specs.

Even with an identical font, however, a font-renderer can use or ignore
font-rendering hints on different platforms. For example, kerning,
tracking, fractional-metrics, and anti-aliasing all come into play in how a
font gets turned into pixels. And only some of those are accessible to
Java.

-- GG
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Be sure to read the FAQ http://developer.apple.com/java/faq/ before posting
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.