Xorg and Fonts
rjshaw at netspace.net.au
Tue Aug 30 22:12:26 PDT 2005
James Cloos wrote:
>>>>>>"Russell" == Russell Shaw <rjshaw at netspace.net.au> writes:
> Russell> The proponents of client-side fonts gave no valid reason for
> Russell> disregarding server-side fonts
> There were valid reasons given. The clients need access to most if
> not all of the data in a modern font anyway, so the server would have
> to provide access to all of those tables. And there are several
> competing standards for what tables to put in sfnt fonts, regardless
> of whether the actual glyphs are in glyf or cff tables.
The idea i have is that regardless of the format of end font-tables,
all the required information is converted to a canonical format that
the client needs for font calculations.
> Or, if the
> server were to handle all of the complex typesetting, every time a
> glyph or string of glyphs is set it would have to send a copy of the
> resulting pixmap back to the client so that the client could know what
> is there.
That is what i confirmed as a valid point.
> It is much easier to update a library or two on the client
> side than to get new X servers installed. A change in server-side
> fonts requires a new X extension, and you've seen by how long it took
> to fully support the RENDER extension how hard that is. And if you
> can install software you can install fonts, too.
In the new setup, a new font only requires a new external agent from
the X server, just like adding any other hardware:
System interface agents.
| X server |<--- /dev/Xinput <--- | One or more X event generators |
| |---> /dev/Xoutput ---> | and readers. |
+----------+ | X events for mouse button presses |
| and movement etc, |
| X events for keypress, keyrelease etc, |
| X events for hardware changes. |
| Requests from server to reset or query |
| hardware. |
| X event to notify the root window or an|
| application window of a font change |
| request. |
> In the cases where there is a desire to have only a single physical
> store for some fonts, network filesystems can server those to the X
> client apps.
Impractical for a country-wide publicly accessible X client machine, or even
for large institutions. NFS can be insecure too.
> Russell> This doesn't solve the problem of not being able to use your
> Russell> own fonts when the client is running on a remote machine you
> Russell> have no unix shell account on.
> How do you run such an app? How do you manage it?
Just like a web browser. In your url box, enter eg: x11://www.taxoffice.com
and you get a nice responsive X program running in your browser window where
you can do things like modify database details or even draw pictures in a
graphics program as the remote client. You could also have a secure option
where the user needs to enter a password.
If you have a shell account on the remote machine, you can start the
client as "normal" in X.
The user can load a local file they want to work on with a normal file-open
dialog box, and it gets uploaded to the remote client. If the client uses
a password or cookies, then they can return to continue the session later
and download the file to their own pc.
It makes html redundant if you want a fine-grained and responsive user
interface. I've thought of further ways to dramatically reduce the X
protocol traffic compared to current X11.
> Russell> If the client is internationalized, the client machine might
> Russell> need a few megabytes of font files for every language.
> A few megs per language is a gross exaggeration for UI fonts. Only
> fine typesetting -- with a wide variety of font weights, widths and
> optical sizes -- could need that much. A few megs total, for all
> current scripts is more realistic. And not out of line with the sizes
> of apps these days. And a fully internationalized app will need to
> deal with some *very* complex scripts.
> Russell> A hypothetical example would be an online database that is
> Russell> across the country or international. Normally, you'd make a
> Russell> web interface for it using php or java on the web server. As
> Russell> everyone knows, there's a significant time lag when
> Russell> interacting with web interfaces due to having to download
> Russell> complete pages of html, unless you put more interactive stuff
> Russell> You could instead make an X interface. ...
> I agree that a web app is not the best solution. But I disagree that
> X11 is the right protocol. I'd write a GUI targetting something like
> pyGTK/pycairo (python bindings to GTK and cairo) and use a mroe
> customized stream protocol between the app-server and the app-client
> (the latter then also being an x-client). Ideally the protocol would
> be the DB's (secured) protocol, but if a barrier is required between
> the client and the SQL something simple using BEEP (rfc 3080) would be
> reasonable. (Perhaps using XML-RPC over BEEP, as in rfc 3529).
> Russell> The argument for client-side fonts is that you need quick
> Russell> access to font metrics.
> It isn't just metrics. It is /all/ of the information. The various
> sfnt tables (OpenType, AAT, Graphite, proposed X11 and TeX tables,
> and various proprietary tables all exist and are relevant to
> converting from character strings to rendered glyphs. And both sides
> need to know the results of alpha blending et al.
I'll think more on a canonical format.
> Russell> I'm not sure if the facility to upload a large font metrics
> Russell> file from the X server to the client is currently
> Russell> available.
> OK. You just gave me an idea. In general it is better for the apps
> to get access to the fonts via the filesystem, whether a local fs or
> a network fs. But you /could/ embed an entire font in a root-window
> property. The client would need to know to look for such a font, to
> grab it into its own VM, and to be able to use a font that is in mem
> rather than in a file. It would not require an X extension; a local
> app (gui or cli) can provide a means to store the file(s) and client
> apps can easy grab such properties to local storage.
That's what i was getting at, but i enhanced it with the hardware
extension method above.
> The apps to store the files will be easy to write.
> Convincing toolkits to support it will be as hard as convincing them
> to support a new X extension. Perhaps a patch for fontconfig that
> looks for such fonts in addition to those found via the primary
> fonts.conf would be reasonable.
There's no need to convince current toolkits because i'm writing one
that will do all this and more in a space *much* smaller than current
widget kits. It looks like i'll be hacking half the X server and
creating configurator GUIs for it too;) All patches from me have
been ignored by other toolkits, and i've found their internals too
complex to figure out as well (plus i find their designs far too
> I don't know what limits exist on how large the value of a window
> property can be; such limits may make this impossible....
More information about the xorg