Re: [Fonts]Another approach to text in X

[James A. Crippen]

Sergey Babkin <[EMAIL PROTECTED]> writes:

> Alexander Gelfenbain wrote:
> > 
> > On Mon, Feb 25, 2002 at 12:38:28PM -0800, Erik van der Poel wrote:
> > > Alan Coopersmith wrote:
> > > >
> > > > It is our belief that leaving font rendering on the server side will be more
> > > > efficient than sending the bits over from the client side.  Of course, we can't
> > > > prove this until we've actually done it, so we don't know for sure.
> > >
> > > It would be interesting to see the results. I'm curious about laying out
> > > text, drawing it, and selecting it (with the mouse).
> > 
> > Unfortunately we have not yet implemented highlights and hit testing. The idea
> > is that the server will manage an encapsulated text object and it will
> > be able to highlight a selection without exchanging any metrics data with
> > the client.
> 
> How about breaking the text into lines ? You just have to get the
> metrics for separate words in the line and if you split the words
> then of the separate syllables in the last word for that. 

That's not safe for i18n, since some languages don't represent words
with any sort of delimiter in their writing, eg Japanese.  You can't
rely on any sort of delimiter for words, which essentially means that
you'd end up having to do linguistic syntax processing to get this
right.  And that's an AI/NLP problem.

My two cents.

'james

-- 
James A. Crippen <[EMAIL PROTECTED]> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) |  |\  | Earth, Sol System,
Y(F) = F(Y(F))\_,-_/  Milky Way.
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts]Installation of Adobe's free Asian CID fonts

[James A. Crippen]

I just recently downloaded the example CID-keyed fonts that were made
available by Ken Lunde (author of O'Reilly's _Understanding CJKV_) at
ftp://ftp.oreilly.com/pub/examples/nutshell/cjkv/adobe/

In the samples directory there are a bunch of CID-keyed fonts for
Chinese, Japanese, and Korean, including the relevant AFM files.
Lunde also provided the standard CMap files for the following:

  Adobe-CNS1-4
  Adobe-GB1-4
  Adobe-Identity-0
  Adobe-Japan1-4
  Adobe-Japan2-0
  Adobe-Korea1-2

What I'm trying to do is install these into my running XFree86 4.2.0
system (on Linux/x86 2.4).

I started reading README.fonts for instructions on installing these
CID-keyed fonts (section 2.3).  I've gotten up to the point where I
have to create a fonts.scale file.  It's not that I have a problem
understanding the instructions, since they're pretty easy to follow.

The problem I have is whether I really have to create entries for all
50 Adobe-Japan1 CMaps for all four of the Adobe-Japan1 fonts.  Should
I just hack up a sed script that pairs the font names with each and
every CMap?  Or should I ignore most of them and only use a couple
important ones?  If the latter, which CMaps do I care about and which
ones am I likely never to need?

There should be an automated tool like mkfontdir and mkcfm that knows
how to read the CIDFonts and CMap directories and generates the proper
fonts.scale file...  Or is there one already out there that I don't
know about?

On a completely different topic, is there any reason not to bundle the
'type1inst' and 'ttmkfdir' programs with XFree86?  It seems to me that
including them would be a good idea...

'james

-- 
James A. Crippen <[EMAIL PROTECTED]> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) |  |\  | Earth, Sol System,
Y(F) = F(Y(F))\_,-_/  Milky Way.
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Outlines to borrow

[Sergey Babkin]

Roozbeh Pournader wrote:
> 
> I and my team are developing a set of Persian OpenType fonts, to
> contribute to XFree86 (and other projects). Can someone tell me that from
> which fonts may I steal (read borrow) the glyph outlines for ASCII
> characters and other punctuations (open double quotes, etc)?

I have some Public Domain TrueType fonts. The hinting in them
is probably not good but I guess you can use the outlines themselves.
Please let me know if you would want to get them.

-SB
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Another approach to text in X

[Sergey Babkin]

Alexander Gelfenbain wrote:
> 
> On Mon, Feb 25, 2002 at 12:38:28PM -0800, Erik van der Poel wrote:
> > Alan Coopersmith wrote:
> > >
> > > It is our belief that leaving font rendering on the server side will be more
> > > efficient than sending the bits over from the client side.  Of course, we can't
> > > prove this until we've actually done it, so we don't know for sure.
> >
> > It would be interesting to see the results. I'm curious about laying out
> > text, drawing it, and selecting it (with the mouse).
> 
> Unfortunately we have not yet implemented highlights and hit testing. The idea
> is that the server will manage an encapsulated text object and it will
> be able to highlight a selection without exchanging any metrics data with
> the client.

How about breaking the text into lines ? You just have to get the
metrics for separate words in the line and if you split the words
then of the separate syllables in the last word for that. Another
example is the text justification: it either has to be done completely
at the server or again the metrics for separate words should be 
received by the client and used to compute the positions of the words.

-SB
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Outlines to borrow

[Markus Kuhn]

On Thu, Feb 28, 2002 at 05:41:08PM +, Juliusz Chroboczek wrote:
> In addition, you may want to check the GhostScript fonts from URW++
> (in version 6.0 or later) which come under the GPL -- which will make
> your font impossible (or unlikely?) to be included in XFree86.

I thought that in the case of outline fonts and similar data sets, where
there isn't a compilation step and a distinction between source code and
distribution binary, there isn't any difference in practice between the
GPL and the XFree86 licence ... if there is, what exactly is it?

Is there a reason, why a GPL font cannot be included into XFree86 but a
font with licence conditions like has Lucidux can? What exactly is the
difference (except that the GPL was never written for fonts and people
who use it for that purpose don't really know what they are doing)?

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: 

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Standard Type Service Framework (STSF): Public Review

[Alan Coopersmith]

>- the API doesn't explicits the client/server model chosen by
>  the ST team, nor the way it manages/lists installed fonts.
>
>  This means that if the client/server model doesn't provide
>  reasonable benefits (or if it brings too many annoyances),
>  it's still possible to change the implementation to more
>  common things (like a user-side libraries).

This is very true.  In fact, at this early point in the implementation,
while everything is coded to allow for client/server communication to be
dropped into place, the font server is loaded into the client process as
a shared library.  We are still committed to splitting the server process
into it's own address space as we progress in the implementation of ST.

One of our design goals is to make the architecture scalable from a desktop
where the Xserver is the only client to a SunRay server where there may be
hundreds of Xservers and hundreds of other non-X clients, all using ST.
Obviously we won't be able to tell if we succeeded until we actually finish
the implementation.

>  However what would happen if the ST Font Server crashes for one reason
>  or another ?? Is there a way for the extension to re-connect to the
>  server and have its state restored in a coherent state ?

Most of the state is kept in the ST Client Library - there would be some problems
in the current design, such as the CreateFont call which allows applications to
send down a font of their own.  This is definitely something we'll need to include
in our design.

>  However, a fix in XST of ST Client library will need an update of
>  the code providing the XST extension. Any API addition or protocol
>  change as well..

A fix to the ST Client Library should require simply replacing libST.so
on any system with dynamic linking.  Only changes to the ST API or XST
protocol would require changes to the XST server extension.  Since XST
is a non-invasive extension (it requires no changes to the server outside
of handling the new extension requests), it should be dynamically-loadable 
on systems such as XFree86 and Xsun that support such things.

>  I know that you're going to find me picky :o) However, this kind of code is
>  present in both the client and server sources of ST, which means that:
>
>- the FontServer is susceptible of simple crashes in the case of
>  memory exhaustion. Unlikely  but still possible, and with dire
>  consequences..
>
>- the Client library is also susceptible to such crashes. In the
>  event where you'd like to use it within an X Server extension, this
>  could mean that the X Server would crash under the same conditions

We definitely plan to improve the robustness of the ST & XST code as it
evolves.  There are many places where error checking is currently done by
assert that will have to be replaced with non-fatal error checks, as 
killing the Xserver when an assertion fails is not acceptable error handling.

We will take your other comments into consideration - feedback like this is
why we opened up the architecture to public review this early in the process.
We want to make sure we end up with a usable end product and wanted to allow
changes to the design before too much of it was set in stone.

-Alan Coopersmith-  [EMAIL PROTECTED]
 Sun Microsystems, Inc. - Software Systems Group
 Cust. Advocacy & Tech Services: X11 Engineering


___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Outlines to borrow

[Pablo Saratxaga]

Kaixo!

On Thu, Feb 28, 2002 at 05:41:08PM +, Juliusz Chroboczek wrote:

> In addition, you may want to check the GhostScript fonts from URW++
> (in version 6.0 or later) which come under the GPL -- which will make
> your font impossible (or unlikely?) to be included in XFree86.

Why?
I don't think that just distributing the font wih XFree86 would consist
of a "derivative work".
(making new fonts based on it will be, of course).

Or does XFree86 impose some specific licences on fonts to be included ?

-- 
Ki ça vos våye bén,
Pablo Saratxaga

http://www.srtxg.easynet.be/PGP Key available, key ID: 0x8F0E4975

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts]xfs dead but pid file exists

[Ciprian A.]

Hi all,

I just installed Ximian on a Linux machine which already had KDE & Gnome.

I installed it using the directions from Ximian website.

For some reason, now the xfs server doesn't start right anymore.
If I execut /etc/init.d/xfs startI get an [OK] message. But when I 
execute /etc/init.d/xfs status I get a message saying: XFS dead but pid 
file exists.

Any idea what happened and how I can fix this?? (Due to this error some 
programs do not start - "can not find the required fonts").


Thank you in advance,
--Cip--



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Standard Type Service Framework (STSF): Public Review

[Brian Stell]

David,

This is a very nice overview.

I've been to busy at the moment to take an indepth look at ST.

I'd like to comment on several items but before I do I want
to make sure I have all my facts in order.

Do the ST folks want to make comments on this review?

Before we begin drawing conclusing its always good to have
agreement on the basic facts. :)

David Turner wrote:
> 
> Hello,
> 
> Alexander Gelfenbain a écrit :
> >
> > The Sun Microsystems ST team would like to invite open-source developers
> > to participate in the public review of the STSF API.  The API specification
> > can be found on the project web page at http://stsf.sourceforge.net/
> > Discussion and comments on the API should be sent to the
> > [EMAIL PROTECTED] mailing list, which is open to the public
> > and publically archived.
> >
> 
> I've just spent a few hours reading the ST and XST APIs, as well as dug
> within the source code that was made available a few days on SourceForge,
> and I'd like to share my first impressions with you..
> 
> Those who know me a bit will understand that I've focused on the issues
> of abstract-ness and reliability :-)
> 
> I. Regarding the API itself:
> 
> 
>   I like the API, there are several things that I consider good things:
> 
> - the API is simple
> 
> - the API doesn't explicits the font engine (called 'scaler'
>   in ST terminology) used, unlike libXft.. And I do think it's
>   a good thing.
> 
> - the API doesn't explicits the client/server model chosen by
>   the ST team, nor the way it manages/lists installed fonts.
> 
>   This means that if the client/server model doesn't provide
>   reasonable benefits (or if it brings too many annoyances),
>   it's still possible to change the implementation to more
>   common things (like a user-side libraries).
> 
>   That's of course very unlikely, but it's still nice to know
>   that the API doesn't limit your design/implementation too
>   much
> 
> - it uses style objects (like ATSUI), which should considerably
>   ease the development of programs that need to display or print
>   rich-text.
> 
> - it let applications use custom font files/streams
>   (see STTypeEnvCreateFont). Not implemented yet, but
>   I suppose that this will come..
> 
>   Note that there is no provision in the API to perform
>   font sub-setting when it comes to generating embedded font
>   fragments for PDF or Postscript output. However, it seems
>   that some font conversion sources are included in the
>   source file 'opensource/STFontServer/sft.c'
> 
>   it's possible to output individual text to outlines, which
>   means converting text to graphical Postscript or PDF though..
> 
>   On the other hand, I don't see _any_ way to perform consistent
>   WYSIWYG text with this API, since its packs both glyph shaping
>   and (device-specific) text layout in a single pass.
> 
>   I find this quite strange and I'd like to know if there's
>   something that I didn't understand in the API, or if this simply
>   is a "design feature" ?
> 
>   I know that it's not important in 90% of cases, but I do care for
>   the subtle effects of hinting on line widths and justification :o)
> 
> II. Regarding the client/server design:
> ---
> 
>   I don't think that many people on these lists understands how how
>   the ST framework is designed, so here are a few more explanations:
> 
>   ST is designed around a client/server model that is, it's important,
>   completely independent of any X11 issues. A stand-alone Font Server
>   process runs and manages font listing/installation as well as
>   processes font files and perform text layout.
> 
>   Another important point is that application are able to choose
>   the font engines (called Scalers in ST terminology) they want to
>   use, even if they'll never access them directly. Instead, this
>   is done in the font server exclusively..
> 
>   Basically, when a simple application wants to render text with ST
>   on, say, a PNG pixmap, with the FreeType 1.x font engine,
>   the following will happen:
> 
>+---+ +---+
>| +---+ | | +---+ |
>| |   | | | |   | |
>| | ST Client | <-> |ST Font Server | |
>| |  library  | | | | code  | |
>| |   | | | |   | |
>| +---+ | | +---+ |
>|   | | +---+ |
>|   | | |   | |
>|   | | | FreeType 1.x  | |
>| +---+ | | | (dynamically loaded)  | |
>| |   | | 

Re: [Fonts]Outlines to borrow

[Juliusz Chroboczek]

RP> I and my team are developing a set of Persian OpenType fonts, to
RP> contribute to XFree86 (and other projects). Can someone tell me that from
RP> which fonts may I steal (read borrow) the glyph outlines for ASCII 
RP> characters and other punctuations (open double quotes, etc)?

The Bitstream fonts (Charter and friends): probably yes, but I don't
remember for sure.

IBM Courier and Adobe Utopia: probably not, but does anybody actually
know?

Luxi/Lucidux: definitely not.

In addition, you may want to check the GhostScript fonts from URW++
(in version 6.0 or later) which come under the GPL -- which will make
your font impossible (or unlikely?) to be included in XFree86.

Juliusz

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Outlines to borrow

[Roozbeh Pournader]

On Thu, 28 Feb 2002, Mark Leisher wrote:

> Hmm.  I guess it would depend on the style of the Persian letters,

So I need a list.

> but does the license of Code2000 allow something like this?

No, Code2000 is a shareware demo. I thought there may be something in
XFree86. Checked Luxi and found that I cannot borrow outlines from it.
Thought that I should better ask.

roozbeh

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Outlines to borrow

[Mark Leisher]

Roozbeh> I and my team are developing a set of Persian OpenType fonts, to
Roozbeh> contribute to XFree86 (and other projects). Can someone tell me
Roozbeh> that from which fonts may I steal (read borrow) the glyph
Roozbeh> outlines for ASCII characters and other punctuations (open double
Roozbeh> quotes, etc)?

Hmm.  I guess it would depend on the style of the Persian letters, but does
the license of Code2000 allow something like this?
-
Mark LeisherOrthodoxy, of whatever color, seems to
Computing Research Lab  demand a lifeless, imitative style.
New Mexico State University
Box 30001, Dept. 3CRL  -- Politics and the English Language,
Las Cruces, NM  88003 George Orwell
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts]Outlines to borrow

[Roozbeh Pournader]

I and my team are developing a set of Persian OpenType fonts, to
contribute to XFree86 (and other projects). Can someone tell me that from
which fonts may I steal (read borrow) the glyph outlines for ASCII 
characters and other punctuations (open double quotes, etc)?

roozbeh

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Standard Type Service Framework (STSF): Public Review

[David Turner]

Hello,

Alexander Gelfenbain a écrit :
> 
> The Sun Microsystems ST team would like to invite open-source developers
> to participate in the public review of the STSF API.  The API specification
> can be found on the project web page at http://stsf.sourceforge.net/
> Discussion and comments on the API should be sent to the
> [EMAIL PROTECTED] mailing list, which is open to the public
> and publically archived.
>

I've just spent a few hours reading the ST and XST APIs, as well as dug
within the source code that was made available a few days on SourceForge,
and I'd like to share my first impressions with you..

Those who know me a bit will understand that I've focused on the issues
of abstract-ness and reliability :-)


I. Regarding the API itself:


  I like the API, there are several things that I consider good things:

- the API is simple

- the API doesn't explicits the font engine (called 'scaler'
  in ST terminology) used, unlike libXft.. And I do think it's
  a good thing.

- the API doesn't explicits the client/server model chosen by
  the ST team, nor the way it manages/lists installed fonts.

  This means that if the client/server model doesn't provide
  reasonable benefits (or if it brings too many annoyances),
  it's still possible to change the implementation to more
  common things (like a user-side libraries).

  That's of course very unlikely, but it's still nice to know
  that the API doesn't limit your design/implementation too
  much


- it uses style objects (like ATSUI), which should considerably
  ease the development of programs that need to display or print
  rich-text.


- it let applications use custom font files/streams
  (see STTypeEnvCreateFont). Not implemented yet, but
  I suppose that this will come..

  Note that there is no provision in the API to perform
  font sub-setting when it comes to generating embedded font
  fragments for PDF or Postscript output. However, it seems
  that some font conversion sources are included in the
  source file 'opensource/STFontServer/sft.c'

  it's possible to output individual text to outlines, which
  means converting text to graphical Postscript or PDF though..



  On the other hand, I don't see _any_ way to perform consistent
  WYSIWYG text with this API, since its packs both glyph shaping
  and (device-specific) text layout in a single pass.

  I find this quite strange and I'd like to know if there's
  something that I didn't understand in the API, or if this simply
  is a "design feature" ?

  I know that it's not important in 90% of cases, but I do care for
  the subtle effects of hinting on line widths and justification :o)



II. Regarding the client/server design:
---

  I don't think that many people on these lists understands how how
  the ST framework is designed, so here are a few more explanations:

  ST is designed around a client/server model that is, it's important,
  completely independent of any X11 issues. A stand-alone Font Server
  process runs and manages font listing/installation as well as
  processes font files and perform text layout.

  Another important point is that application are able to choose
  the font engines (called Scalers in ST terminology) they want to
  use, even if they'll never access them directly. Instead, this
  is done in the font server exclusively..


  Basically, when a simple application wants to render text with ST
  on, say, a PNG pixmap, with the FreeType 1.x font engine,
  the following will happen:

   +---+ +---+
   | +---+ | | +---+ |
   | |   | | | |   | |
   | | ST Client | <-> |ST Font Server | |
   | |  library  | | | | code  | |
   | |   | | | |   | |
   | +---+ | | +---+ |
   |   | | +---+ |
   |   | | |   | |
   |   | | | FreeType 1.x  | |
   | +---+ | | | (dynamically loaded)  | |
   | |   | | | |   | |
   | |Application| | | +---+ |
   | |   code| | +---+
   | |   | |
   | +---+ |  Font Server process
   +---+

  Application process

  The SF Font Server is in charge of the following different
  features:

A - manage font installation/listing (i.e. scanning font
path directories, enumerating valid font files in them,
etc..)

B - load/unload font engines

C -