Re: [9fans] plan9 font service [WAS: abaco @ plan9port]

["Federico G. Benavento" <benavento@gmail.com>]

there was a fontfs years ago.

Oleg was working on the abaco port, he tweaked some stuff yesterday
you can get it from http://abaco.oitobits.net

On Thu, Mar 13, 2008 at 11:33 AM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Enrico Weigelt <weigelt@metux.de> wrote:
>  >
>  > now another problem: abaco expects some fonts in
>  > /usr/local/plan9/fonts.
>  >
>  > Seems we need some convenient way for relocating fonts.
>  > Maybe an even an fontserver ? ;-)
>
>  I've now manually tweaked the pathes in the source, but this
>  isn't really a good solution ;-o
>
>  Maybe we should introduce some font server (maybe a little bit
>  like X has one). This font server represents all (virtually)
>  available raster fonts (even autogenerated or remotely fetched)
>  in some convenient namespace, so an client only has to open one
>  file to get an complete font. (maybe we should also invent some
>  complete-font file format instead of splitting them into subfonts
>  in the client's view).
>
>  In the end, an client should never directly access font files,
>  but instead query the font server.
>
>  BTW: an interesting thing would be an high-level display server,
>  which is capable of complex operations, eg. viewports, font and
>  image rendering (maybe something between X and windows' DCs ?).
>  The client would only have to send hi-level ops and leave the
>  dirty work to an (maybe hw accelerated) display server.
>
>
>  cu
>  --
>  ---------------------------------------------------------------------
>   Enrico Weigelt    ==   metux IT service - http://www.metux.de/
>  ---------------------------------------------------------------------
>   Please visit the OpenSource QM Taskforce:
>         http://wiki.metux.de/public/OpenSource_QM_Taskforce
>   Patches / Fixes for a lot dozens of packages in dozens of versions:
>         http://patches.metux.de/
>  ---------------------------------------------------------------------
>
>



--
Federico G. Benavento