Re: [Fonts] Re: [ft] Creating an [OT]TF font from BDF font
George Williams wrote:
I downloaded fonttosfnt from x.org's cvs repository.
So I suggest the following patch (I have no write access to the cvs tree
myself)
To get patches into code in X.Org's CVS, please file bug reports at:
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
and then use the "Create Attachment" link in the resulting bug report to
attach the patch to it.
--
-Alan Coopersmith- [EMAIL PROTECTED]
Sun Microsystems, Inc. - X Window System Engineering
___
Fonts mailing list
Fonts@XFree86.Org
http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Helvetica font question for Xfree86
Brett Elliott wrote: I have a font dilemma and I was hoping that you could help me out. I am the Technical Lead for display software development for the International Space Station and we are currently changing our Operating System from Solaris 2.5 (I know that is old) to Redhat Linux 9.0. The problem is that our software is heavily dependent on the font and the Adobe Helvetica font distributed with Redhat 9.0 is not close enough to the Adobe Helvetica font on Solaris 2.5. There are multiple versions of the Helvetica fonts on Solaris 2.5. There are the standard bitmaps in pcf format in the 100dpi & 75dpi directories, which should be similar to those you can get from X.org & XFree86. There are also scalable versions - an F3 version (which lists itself as -linotype-helvetica-...) and a PostScript Type1 version (which claims to be -adobe-helvetica-...). The F3 version would be first in the default font path - but F3 is a dead proprietary format for which there is no support in XFree86. XFree86 should be able to handle the PostScript version, but you won't get the same appearance as XFree86 will use either the Adobe-donated PostScript rasterizer or FreeType to scale the fonts, while Xsun uses the XATM built into Display PostScript, which uses Adobe's very proprietary PostScript font rasterizer to get higher quality output. (There's also a set of pcf bitmaps in the F3bitmaps directory which correspond to the F3 -linotype-helvetica-...) Also, what is the legality of using the font from the Solaris package on a Redhat 9.0 distribution? I think it's a violation of the license agreeement, but I'm no lawyer. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Render in X.org & other Xservers
In the "Removing core support from Xft" discussion back in Dec. 2001, Marcus Kuhn wrote: >What's the schedule for getting RENDER into the X11 standard and >Sun's X servers? I've spent some time looking into this, and there are a couple of things that I think are necessary to get this going at both X.org & the other vendors: 1) Draw a line in the sand (say at what's done in XFree86 4.2.0 or 4.3.0) and declare that to be RENDER 1.0. Either finish the spec, or leave the transformations and other bits that still aren't defined out until version 1.1 -- just set a stable, complete spec instead of the current unfinished spec. Agree that future versions will be backwards compatible. 2) Document the API. I can't find any formal documentation of the API, just the headers/source & the extension protocol documentation. Someone could probably combine those two into the start of an API spec. I can't speak for all the commercial vendors, but at least Sun is very concerned with stable interfaces, as our OS release cycles are now about 2 years long, and while the existing bits of the Render API seem stable, the documentation says that much work remains to be done and it's unclear if that includes changes to the existing protocol/API. Since we promise customers that we only make incompatible changes with prior notice in the next marketing release (i.e. Solaris 8, 9, 10, not the update releases that come out every few months), we don't want to be caught adopting RENDER, then finding out that it's changed incompatibly and we will spend the next three years with an incompatible version of an extension we added primarily to be compatible with XFree86. It's much easier for us to add incremental, backwards compatible, features, than to make wholesale changes to existing features. -- -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]Standard Type Service Framework (STSF): Public Review
>- 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]Another approach to text in X
>Will it be possible to use the ST API to print even when there is no X
>server running? Will ST print using languages other than PostScript?
ST does not require X and does not print itself. I have implemented a
simple demo using GD that uses ST to render text to PNG images without
ever touching X (it's available in the sample code directory of the ST
source distribution). There is nothing restricting a print engine using ST
from outputing PostScript, PCL or a raster file format - ST will support
both outline and bitmap output at any resolution you can specify.
-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] Complex text layout and mapping screen coordinates
Keyur Shroff wrote:
> Since introduction of anti-aliased text in X11 is not violation
> of X protocol, how can one consider changing [x,y] position
> of a glyph as violation of it?
You're confusing what is defined in the core protocol with
what is possible using requests outside the core protocol.
Drawing anti-aliased text in response to PolyText or one of
the other text requests defined in the core protocol would
be a violation of the definitions of those requests in the X
protocol, which is why it's not done that way, but via an
extension.
--
-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]Another approach to text in X
Erik van der Poel wrote: > > Alan Coopersmith wrote: > > > > On top of ST, we have > > layered a new extension to the X protocol, called XST, which > > incorporates the ST functionality. > > I had a look at the stsf.sourceforge.net site, and saw the client API > spec. Looks good. I'm curious about the XST protocol extension. The Web > site says that an XST doc will appear soon. Will that doc also contain a > rationale for this extension? The XST client API doc is up now, the protocol extension spec is still being finished, but mostly follows from the client API. Neither one currently contains a rationale statement, but we can think about adding one. 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. We also think that having the text in the server may provide additional benefits, such as allowing accessibility solutions to access the text of clients who don't use an accessibility-enabled toolkit. We've tried to design the XST api so it can work either with a XST-enabled X server, or by directly linking with ST, on a non-XST enabled X server. This should allow us to test and see which approach is better in the long run, once we finish implementing both methods. -- -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
[Fonts]Re: [I18n]Another approach to text in X
Brian Stell wrote:
>Documentation please.
We are preparing the documentation for a release in early January for review
and comments on the draft specifications. We are working on setting up the
usual infrastructure (public mailing lists, web site, etc.) so we can work with
everyone on this.
-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
[Fonts]Another approach to text in X
Over the past few months, a team of Sun engineers with experience in X
internals, internationalization, and fonts have been working on a
proposed new text architecture for X. We've all been watching the
discussion of various font & text problems and proposed solutions on
mailing lists such as the XFree86 lists, but have had to keep quiet
pending management approval to discuss our project openly.
The Sun project was started because the current X font and text
mechanisms are dated and do not meet the needs of globalized
applications. We have designed a display and platform-independent text
architecture, the Standard Type Services (ST) framework, which handles
not just font rendering, but text layout and font management as well.
ST incorporates typographically sophisticated features and ideas from
the best regarded existing APIs, including Apple Type Services for
Unicode Imaging (ATSUI) and Java2D TextLayouts. On top of ST, we have
layered a new extension to the X protocol, called XST, which
incorporates the ST functionality. The ST API will also be exposed to
applications independant of the X environment so that it can be used
for Java servlets and applets and text rendering to printers, image files,
and other displays.
The ST Framework provides a scalable client-server architecture that
allows multiple clients to share access to common fonts, while
allowing applications with private fonts to keep them private. ST
provides a pluggable API through which many font scalers can be used
by the Font Server, including handling of "smart font" technology such
as OpenType & TrueType GX. Plugins for several font scalers are
available today, each providing a different set of capabilities,
properties and licenses, but unified under a single API for the
client.
The ST API includes functions for font management, rendering, text
layout, and access to all available information about the font,
including access to outlines for output to vector devices. ST is
designed around Unicode and support for languages requiring complex
text layout is included as a core part of the design.
We are preparing to release ST under a X/BSD-style license, and once
that happens, we plan to work with the XFree86, X.org, and li18nux.org
communities to make sure ST & XST meet the needs of the widest
audience. We will send a further announcement to these groups when
the ST materials are released.
- The ST Core Team:
Alex Gelfenbain [EMAIL PROTECTED]
Alan Coopersmith[EMAIL PROTECTED]
Jay Cotton [EMAIL PROTECTED]
Jay Hobson [EMAIL PROTECTED]
Stuart Kreitman [EMAIL PROTECTED]
X11 & Globalization Technology Group
Sun Microsystems, Inc.
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
