Xorg and Fonts

[Russell Shaw]

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> on the users end with javascript in the browser.
> 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
inelegant).

> I don't know what limits exist on how large the value of a window
> property can be; such limits may make this impossible....
> 
> -JimC