Re: [Fonts]Another approach to text in X
Certainly you will have to send some metrics information back to the client when you are doing line breaking, but it is likely to be fewer roundtrips than sending back metrics of all the glyphs that constitute the line. When doing line-breaking the server will be also sometimes decomposing the ligatures or doing some other kind of post-processing. ST is quite flexible regarding line-breaking algorithms, it can do automatic line breaking for you with STLineNewForWidth() which is a quick and easy way of breaking text into lines. It is definitely not a proper line breaking algorithm, but it will certainly be useful in a variety of cases. Or you can do a loop on the client that does analyze source text STLineGrow() / STLineShrink() STLineMeasureText() until you have what you want. Justification, on the other hand, can be performed entirely on the server side with no roundtrips. The server needs to know the imposed line width (text area width) and the line itself. This information is already there. AG On Thu, Feb 28, 2002 at 10:39:33PM -0500, Sergey Babkin wrote: 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 -- Alexander Gelfenbain, Sun Microsystems, Inc. +1 (408) 635-0612 ___ 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]Another approach to text in X
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). 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. I wonder if it would be better to design and deploy a good accessibility 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. In the latter case, is the ST library on the X client side? Are you then using the normal X protocol? The ST project certainly looks very promising. How's it going on the printing side? Did you get the ST API to print on Linux? Thanks, Erik ___ 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
Re: [Fonts]Another approach to text in X
Around 9 o'clock on Feb 23, 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. I'm excited about having another new API for text layout; the problems are hard, and I think we have a long ways to go before the right API becomes obvious. More implementations will really help this issue. However, I feel that the underlying infrastructure supporting the ST API is moving in the wrong direction. XST vs Xft: I believe ST could easily be completely implemented on top of the existing Xft/fontconfig/FreeType library APIs for accessing fonts and their related data. This would provide significant benefits for everyone: + ST implementation can progress independently of any other X work. + ST will run efficiently on current XFree86 servers with no need to wait for the two year deployment cycle for new X extensions. + ST will run on all X servers and include AA/LCD text on legacy TrueColor servers + ST-based applications will share font configuration with all other Xft/fontconfig-based systems (Qt, Gtk+, Mozilla) + Applications can migrate to ST-based text output incrementally, confident that their font selections will remain consistent across the user interface. + No protocol dependencies on font capabilities; migrating to new unimagined font formats can happen as quickly as a new library can be made available. Using a custom extension with core-fallback code would cause many problems: - Yet another X extension to deply and maintain. - Yet another font configuration and customization mechanism - Unresolved issues of system and network performance - Protocol may restrict future font capabilities. Text Performance and the Render Extension: When considering client-side text during the design of the Render extension, I did a quick calculation to show that for non-AA text, Render would use no more bytes on the wire than the core protocol -- the core must transfer the metrics for every glyph in the font to the client so that it can perform layout. Those metrics consume 16 bytes per glyph. A typical 12 pixel font consumes some 20 to 30 bytes per glyph image. Because core X must transmit *all* of the metrics for the font, and because most text uses less than half of the glyphs in any particular font, even in 8-bit encodings like Latin-1, it was evident that client-side text wasn't a crazy idea. AA text doesn't increase the size of the data significantly; our 12 pixel font may now consume some 50 bytes of data per glyph. Once I had the protocol up and running and had ported some real applications, I made some measurements comparing server-side core text to client-side Render text. The data I've collected indicate that even for simple text, the Render extension is more efficient than the current core protocol. While the total bandwidth consumed rose modestly when switching from core to AA text, that increase was more than offset by the decrease in the amount of time applications spent waiting for data from the X server, both to get the metrics for each font, and also in inquiries about the set of available fonts. From my understanding of how the XST extension works, adding sophisticated layout to the mix will require many more round trips as the client can no longer compute display metrics for text locally. It seems that just to center text in a button will require a round trip to the X server each time the text is altered. Here's a presentation I did about why LBX was a failure: http://www.xfree86.org/~keithp/talks/lbxpost/ The data in this presentation shows that bandwidth is not a serious problem for X performance, except for images. The real performance bottleneck has always been latency -- here's a slide from that talk: http://www.xfree86.org/~keithp/talks/lbxpost/slide-16.html The numbers presented are for a synthetic network with 30ms RTT and 300Kbps bandwidth. Faster networks don't significantly alter the ratio between these two factors (100Mb network has about .1ms RTT, a factor of 300 for both values). Note that application startup time for the core-text applications (Netscape and the Gimp) are both dominated by the application simply waiting for data from the X server; the wire is idle around 70% of the time. Once core text applications are started, they run relatively asynchronously reducing the latency effect, this makes them relatively efficient after startup. By placing all of the text management within the application address space, the Render extension eliminates all latency concerns during application startup and execution -- there is no information that the X server has other than that provided by the client; Render clients are
Re: [Fonts]Another approach to text in X
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. Have the fonts handled at the server means having to pull the metrics over the the client. Having the fonts handled at the client means having to send the glyph data over to the server. I looked at this and it did not seem dramatically different. Maybe slight more bytes for the client side. To me this pales in comparison to moving images which everyone is doing a lot these days. One place where server side would have an advantage is for sub pixel rendering. A sophisticated app might want to rerender each glyph to get the apperance of subpixel layout. This would give the best WYSIWYG screen display and allow better layout of the printed page. I had this working at one point in an experimental Mozilla build (this was not TrueType related) but I had to back it out because for it to work the layout layer would need to know the subpixel positions to correctly support highlighting. Changing the layout layer to know the subpixel values was not something I had time for at that point. 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. I'm not familiar with this. Could you talk about this a bit more? 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. It will be interesting to see you results. From my perspective one of the critical reasons to move to client side is that people don't change their X server very often so great new features in the X server take a long time to get into wide spread use in the field. Waiting for X server changes takes years. I'd like to see the X environment be a place where new features can move on to user's desktops in weeks or months. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Another approach to text in X
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? Thanks, Erik ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
Mike A. Harris wrote on 2002-02-02 03:15 UTC: It might as well say Sun did not design this software for use in making peanut butter sandwiches if it bares no real meaning. The day /bin/laden finds out how to use beanut butter to kill 3000 US citizens every year (e.g., by merely watching arterio sclerosis doing it's bit), I am sure that the US government will make peanut butter a controlled substance and Sun's diligent lawyers will find it prudent to distance formally any of their products from having anything to do with peanut butter facilities. Otherwise the US lawyers from peanut-butter- arterio-sclerosis victims will come after every single company whose products they have found in peanut-butter factories, sueing them as being terrorist collaborators. ST is obviously not a specialized nuclear facility product. Ok. I still consider the phrase pointless though. Of course it is! That is the whole beauty of it. Accept it as a piece of political art, just like the OpenCola recipe: http://www.opencola.com/products/3_softdrink/formula.shtml meaningless statements that may cause confusion - which is evidenced by the fact this thread has come up in the first place. I'm sorry for having started the thread. It was merely ment as a humouros note and it was irresponsible from me to not consider that it might trigger real concern and legal anxiety in the land-of-lawyers. When such confusion is indeed present, then yes, lawyers must get involved. Does that really help in practice or is it more of a cultural habit? Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: http://www.cl.cam.ac.uk/~mgk25/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
I received the following clarification from our legal people: The changes to the BSD were intended to remain consistent with the Open Source Definition stated by OSI. As such, the statement about nuclear facilities is a notice and not a restriction per se. The BSD+ also re-states the limitation of liability provision consistent with current law. I don't think any additional interpretation is needed: the clause about nuclear facilities is a notice and not a restriction. Regards, AG On Mon, Jan 28, 2002 at 01:03:31PM +0600, Dmitry Yu. Bolkhovityanov wrote: On Thu, 17 Jan 2002, Alexander Gelfenbain wrote: I can confirm that the license ST will be released with is BSD+ which is standard BSD with the following clause: * You acknowledge that this software is not designed, licensed or indended * for use in the design, construction, operation or maintenance of any * nuclear facility. Sorry if it is a stupid question (I'm not a lawyer :), but does this clause mean that if ST somehow gets into Red Hat, SuSE or some other distro, we (see my signature) and other high-energy physics labs will have no legal right to use these distros? Can you please ask your legal department to make that statement more clear? TIA, Dmitry _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts -- Alexander Gelfenbain, Sun Microsystems, Inc. +1 (408) 635-0612 ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
On Wed, 30 Jan 2002, Markus Kuhn wrote: I am afraid that statement in Sun license above exactly means that you can't use this software (ST library) in design, construction, operation or maintenance of any nuclear facility, including nuclear reactors and nuclear weapons. That is how I would interpret it also. Then please read it again or better ask a lawyer to help you reading it, because you have quite clearly misunderstood what it says and interpreted it in an inappropriate and unnecessarily paranoid way. All that Sun asks is to acknowledge that *you* understand that Sun did not design this software for use in nuclear facilities. That is all. Sun is *NOT* forbidding you to do anything with this software! Perhaps that is true, but my point is that a software license is intended to tell you what your legal rights of usage of software are. Putting extraneous comments like that into the file merely causes legal confusion. Since allegedly, wether Sun created the software for use in nuclear facilities or not, what you're saying is that it can be used for such. It might as well say Sun did not design this software for use in making peanut butter sandwiches if it bares no real meaning. It is a trivial formality that they have to add these days to make lawyers happy who are afraid of the US government. It is completely irrelevant for XFree86. In particular, if Red Hat includes this package, it is fine if Red Hat uses it in the fast berrder and HEU processing facilities in its basement. Sun didn't forbid you to do so, they just made it clear to you that that is not what they had in mind specifically. ST is obviously not a specialized nuclear facility product. Ok. I still consider the phrase pointless though. If it is not a restriction, then it is meaningless, and should completely be removed from the license as it would be irrelevant in any case to be completely clear. If you don't understand how lawyers think, then make life easy for yourself by not reading what they write. Ignorance is bliss. Really. The intention of Sun to release this software for free use counts, nothing else. If someone does not understand a software license, then that someone is not ever completely sure of what their legal usage of that software is. If a license contains extra statements that do not add or subtract legal rights from what has been allowed for normal usage of the software, then it is nothing more than meaningless statements that may cause confusion - which is evidenced by the fact this thread has come up in the first place. When such confusion is indeed present, then yes, lawyers must get involved. What I am saying, is that removing such fluff commentary from such a license also would remove the potential confusion surrounding it. It wasn't an attack on someone. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
On Wednesday 30 January 2002 01:25, Alexander Gelfenbain wrote: | I received the following clarification from our legal people: | | The changes to the BSD were intended to remain consistent with the Open | Source Definition stated by OSI. As such, the statement about nuclear | facilities is a notice and not a restriction per se. | | The BSD+ also re-states the limitation of liability provision consistent | with current law. | | I don't think any additional interpretation is needed: the clause about | nuclear facilities is a notice and not a restriction. | | Regards, | AG | ok, thanks a lot for clarification! As people on these lists had some concerns, I guess you need to make some clear statement on ST license nuclear facilities, so ST can be integrated into leading Linux distributions (I guess packagers of those not always read XF Fonts list...) | On Mon, Jan 28, 2002 at 01:03:31PM +0600, Dmitry Yu. Bolkhovityanov wrote: |On Thu, 17 Jan 2002, Alexander Gelfenbain wrote: | I can confirm that the license ST will be released with is BSD+ | which is standard BSD with the following clause: | | * You acknowledge that this software is not designed, licensed or | indended * for use in the design, construction, operation or | maintenance of any * nuclear facility. | | Sorry if it is a stupid question (I'm not a lawyer :), but does |this clause mean that if ST somehow gets into Red Hat, SuSE or some |other distro, we (see my signature) and other high-energy physics labs |will have no legal right to use these distros? | | Can you please ask your legal department to make that statement |more clear? | | TIA, | Dmitry -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: Re: [Fonts]Another approach to text in X
On Tuesday 29 January 2002 20:12, David Smith wrote: | The problem unfortunately, is not with the legal people. Without such | statements the US Government will not allow export of certain technologies. | While I agree with your comments it will require a change of heart in the | US congress to change these restrictions. This is unfortunately unlikely at | present. | I see. But, on the other hand, there is no requirement to ship ST from US. Sun Microsystems had some partners and even Joint Venture in Russia which in fact allowed it to ship 128-bit encryption software outside US just to overcome this limitation. ST is not 128-bit encryption software, so I doubt such excessive steps are necessary. may be, clause can be just excluded from final BSD+ license, so all Linux distributions will have no constrains over incorporating ST. | David | | -Original Message- | From: Vadim Plessky [mailto:[EMAIL PROTECTED]] | Sent: Tuesday, January 29, 2002 1:45 PM | To: [EMAIL PROTECTED]; Alexander Gelfenbain; Markus Kuhn | Cc: [EMAIL PROTECTED] | Subject: [Devel] Re: Re: [Fonts]Another approach to text in X | | On Wednesday 23 January 2002 04:11, Alexander Gelfenbain wrote: | | I don't really know. This clause obviously came from our legal | | department. | | | | AG | | well, from my experience working for one distribution company in Russia: |I (as a representative of that company) always was signing similar | clauses (equipment we sold to you will not be used in nuclear plants, or | for developemtn weapons, etc.) together with yearly distribution contract. | HP (Hewlett-Packard) was in particular very causious with this, as well as | SGI. Probably, Sun (and all other US-based companies) has similar | restriction, and this is caused by US origin of the company. | I also know that one of IBM partners here (in Russia) sold high-end | RS/6000 system to nuclear research labaratory, and IBM had finally to pay | penalties in US because of this deal. | | I believe all this is a heavy heritage of the Cold War, and if we want to | move to the new world, where all people live in peace and in friendship, | we need to stop putting such restriction on software, hardware, facilities, | etc. So, you should talk to legal people and get off these words out of | final software release. Otherwise, it can't be used in Open-Source | projects. | -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
On Mon, 28 Jan 2002, Dmitry Yu. Bolkhovityanov wrote: I can confirm that the license ST will be released with is BSD+ which is standard BSD with the following clause: * You acknowledge that this software is not designed, licensed or indended * for use in the design, construction, operation or maintenance of any * nuclear facility. Sorry if it is a stupid question (I'm not a lawyer :), but does this clause mean that if ST somehow gets into Red Hat, SuSE or some other distro, we (see my signature) and other high-energy physics labs will have no legal right to use these distros? Can you please ask your legal department to make that statement more clear? It is extremely unlikely you will see anything with such a restrictive license on it appear in Red hat Linux. If you know of anything in the distribution with such a license clause, or if anything gets placed into our rawhide developmental releases unknowingly with such a license clause, please let me, or anyone else here at Red Hat know immediately. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
On Tue, 29 Jan 2002, Vadim Plessky wrote: I am afraid that statement in Sun license above exactly means that you can't use this software (ST library) in design, construction, operation or maintenance of any nuclear facility, including nuclear reactors and nuclear weapons. That is how I would interpret it also. While most likely it was standard clause added by Sun to ST library in the same way as for their other software - it is indeed too restrictive and too much different from BSD software license. Very much so. On the second thought - this clause is really not compatible with Open-Source, as it controls the way *how* and *where* I use open-source software. Correct. Such a clause makes it fall way outside the open source definition, and the Debian Free Source Guidelines IMHO. BTW: Linux (and XFree) is used in many different areas, and in design of nuclear facilities weapons as well. If someone wants to restrict usage of either Linux or XFree in some way - well, I guess this software should be distributed separatly from Linux or Xfree86 or major Linux distributions. Precicely. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
On Wed, 30 Jan 2002, Vadim Plessky wrote: Date: Wed, 30 Jan 2002 11:34:17 + From: Vadim Plessky [EMAIL PROTECTED] To: Alexander Gelfenbain [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: XFree86 Font List fonts.XFree86.Org Subject: Re: [Devel] Re: [Fonts]Another approach to text in X On Wednesday 30 January 2002 01:25, Alexander Gelfenbain wrote: | I received the following clarification from our legal people: | | The changes to the BSD were intended to remain consistent with the Open | Source Definition stated by OSI. As such, the statement about nuclear | facilities is a notice and not a restriction per se. | | The BSD+ also re-states the limitation of liability provision consistent | with current law. | | I don't think any additional interpretation is needed: the clause about | nuclear facilities is a notice and not a restriction. | | Regards, | AG | ok, thanks a lot for clarification! As people on these lists had some concerns, I guess you need to make some clear statement on ST license nuclear facilities, so ST can be integrated into leading Linux distributions (I guess packagers of those not always read XF Fonts list...) If it is not a restriction, then it is meaningless, and should completely be removed from the license as it would be irrelevant in any case to be completely clear. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
Mike A. Harris wrote on 2002-01-30 11:11 UTC: I am afraid that statement in Sun license above exactly means that you can't use this software (ST library) in design, construction, operation or maintenance of any nuclear facility, including nuclear reactors and nuclear weapons. That is how I would interpret it also. Then please read it again or better ask a lawyer to help you reading it, because you have quite clearly misunderstood what it says and interpreted it in an inappropriate and unnecessarily paranoid way. All that Sun asks is to acknowledge that *you* understand that Sun did not design this software for use in nuclear facilities. That is all. Sun is *NOT* forbidding you to do anything with this software! It is a trivial formality that they have to add these days to make lawyers happy who are afraid of the US government. It is completely irrelevant for XFree86. In particular, if Red Hat includes this package, it is fine if Red Hat uses it in the fast berrder and HEU processing facilities in its basement. Sun didn't forbid you to do so, they just made it clear to you that that is not what they had in mind specifically. ST is obviously not a specialized nuclear facility product. If it is not a restriction, then it is meaningless, and should completely be removed from the license as it would be irrelevant in any case to be completely clear. If you don't understand how lawyers think, then make life easy for yourself by not reading what they write. Ignorance is bliss. Really. The intention of Sun to release this software for free use counts, nothing else. Back to real problems ... Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: http://www.cl.cam.ac.uk/~mgk25/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
On Thu, 17 Jan 2002, Alexander Gelfenbain wrote: I can confirm that the license ST will be released with is BSD+ which is standard BSD with the following clause: * You acknowledge that this software is not designed, licensed or indended * for use in the design, construction, operation or maintenance of any * nuclear facility. Sorry if it is a stupid question (I'm not a lawyer :), but does this clause mean that if ST somehow gets into Red Hat, SuSE or some other distro, we (see my signature) and other high-energy physics labs will have no legal right to use these distros? Can you please ask your legal department to make that statement more clear? TIA, Dmitry _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
On Monday 28 January 2002 07:03, Dmitry Yu. Bolkhovityanov wrote: | On Thu, 17 Jan 2002, Alexander Gelfenbain wrote: |I can confirm that the license ST will be released with is BSD+ which |is standard BSD with the following clause: | | * You acknowledge that this software is not designed, licensed or |indended * for use in the design, construction, operation or |maintenance of any * nuclear facility. | | Sorry if it is a stupid question (I'm not a lawyer :), but does | this clause mean that if ST somehow gets into Red Hat, SuSE or some other | distro, we (see my signature) and other high-energy physics labs will | have no legal right to use these distros? Hello Dmitry, others! I am afraid that statement in Sun license above exactly means that you can't use this software (ST library) in design, construction, operation or maintenance of any nuclear facility, including nuclear reactors and nuclear weapons. While most likely it was standard clause added by Sun to ST library in the same way as for their other software - it is indeed too restrictive and too much different from BSD software license. On the second thought - this clause is really not compatible with Open-Source, as it controls the way *how* and *where* I use open-source software. BTW: Linux (and XFree) is used in many different areas, and in design of nuclear facilities weapons as well. If someone wants to restrict usage of either Linux or XFree in some way - well, I guess this software should be distributed separatly from Linux or Xfree86 or major Linux distributions. | | Can you please ask your legal department to make that statement | more clear? | | TIA, | Dmitry | | _ | Dmitry Yu. Bolkhovityanov | The Budker Institute of Nuclear Physics | Novosibirsk, Russia -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
RE: [Devel] Re: Re: [Fonts]Another approach to text in X
The problem unfortunately, is not with the legal people. Without such statements the US Government will not allow export of certain technologies. While I agree with your comments it will require a change of heart in the US congress to change these restrictions. This is unfortunately unlikely at present. David -Original Message- From: Vadim Plessky [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 1:45 PM To: [EMAIL PROTECTED]; Alexander Gelfenbain; Markus Kuhn Cc: [EMAIL PROTECTED] Subject: [Devel] Re: Re: [Fonts]Another approach to text in X On Wednesday 23 January 2002 04:11, Alexander Gelfenbain wrote: | I don't really know. This clause obviously came from our legal | department. | | AG well, from my experience working for one distribution company in Russia: I (as a representative of that company) always was signing similar clauses (equipment we sold to you will not be used in nuclear plants, or for developemtn weapons, etc.) together with yearly distribution contract. HP (Hewlett-Packard) was in particular very causious with this, as well as SGI. Probably, Sun (and all other US-based companies) has similar restriction, and this is caused by US origin of the company. I also know that one of IBM partners here (in Russia) sold high-end RS/6000 system to nuclear research labaratory, and IBM had finally to pay penalties in US because of this deal. I believe all this is a heavy heritage of the Cold War, and if we want to move to the new world, where all people live in peace and in friendship, we need to stop putting such restriction on software, hardware, facilities, etc. So, you should talk to legal people and get off these words out of final software release. Otherwise, it can't be used in Open-Source projects. | | On Sun, Jan 20, 2002 at 03:13:22PM +, Markus Kuhn wrote: |Alexander Gelfenbain wrote on 2002-01-17 19:59 UTC: | I can confirm that the license ST will be released with is BSD+ | which is standard BSD with the following clause: | | * You acknowledge that this software is not designed, licensed or | indended * for use in the design, construction, operation or | maintenance of any * nuclear facility. | |Just curious: Was this a legal or political requirement? | |I'm not sure, high energy physics on the other side of the street from |here will in practice be aware of such a strange restriction, once they |get this package via the next SuSE or Solaris update on their office |machines. They are in the profession of doing rather cruel things to |atomic nuclei and design and run facilities to do so. | | We are working on publicly releasing the docs and placing the source | code on sourceforge or some other public CVS server. Please stay | tuned. | |I'm very much looking forward to seeing it. | |Markus -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/ ___ Devel mailing list [EMAIL PROTECTED] http://www.freetype.org/mailman/listinfo/devel ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [I18n]Re: [Fonts]Another approach to text in X
David Turner wrote: ... I didn't find that Brian Stell was harsh in any way.. Announcements are great things, but Sun has a history of disappointing the Open Source community. I'm pretty certain that the ST team is good-hearted and talented, I simply fear Sun's management and the SCSL :o) Just to be clear: I have not made any statement on the goodness or not-goodness of this work or any previous work by Sun. I would like to see what they have done as the international features in the X environment primarily came out of an older era. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
On Sun, Dec 23, 2001 at 11:46:23AM +0100, David Turner wrote: ... Regarding ST, I have been rather pleased by Sun's announcement, even if I'll keep being skeptical until we see the source code and more importantly the _real_ license. The description doesn't give a lot of details regarding the API or internals, but I'm rather pleased to see it because I think that the association of ATSUI and Java2D is probably going to be a _very_ good thing to use.. (this would also mean that we wouldn't need to write the code to implement everything described above..) I didn't find that Brian Stell was harsh in any way.. Announcements are great things, but Sun has a history of disappointing the Open Source community. I'm pretty certain that the ST team is good-hearted and talented, I simply fear Sun's management and the SCSL :o) But if it really comes with a BSD/X-styled license and has all the features I envision, this is going to be a _giant_ leap for Open Source and X in general, and I don't think there should be any good reason to avoid it.. !! I'm now waiting to see more before making a decision on ST, as anyone else.. In the meantime, I'll continue slowly what I've planned.. I can confirm that the license ST will be released with is BSD+ which is standard BSD with the following clause: * You acknowledge that this software is not designed, licensed or indended * for use in the design, construction, operation or maintenance of any * nuclear facility. We are working on publicly releasing the docs and placing the source code on sourceforge or some other public CVS server. Please stay tuned. AG P.S. The full text of license follows: /* * Copyright © 2001, 2002, Sun Microsystems, Inc. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * * 3. Neither the name of Sun Microsystems, Inc. nor the names of its *contributors may be used to endorse or promote products derived from *this software without specific prior written permission. * * This software is provided AS IS, without a warranty of any kind. * * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. * SUN AND ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES OR * LIABILITIES SUFFERED BY LICENSEE AS A RESULT OF OR RELATING TO USE, * MODIFICATION OR DISTRIBUTION OF THE SOFTWARE OR ITS DERIVATIVES. * IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, * PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, * INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE * THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR INABILITY TO USE * SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * You acknowledge that this software is not designed, licensed or indended * for use in the design, construction, operation or maintenance of any * nuclear facility. * */ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
Hello Martin, [EMAIL PROTECTED] a écrit : Dear David, - A text layout engine, based on UniType, supporting all kinds of sophisticated features (including OpenType, we haven't really touched GX for the lack of fonts to test and interest we ourselves have in the technology). May I humbly commend http://graphite.sil.org to you. Thanks a lot, I knew about Graphite but didn't realized it was open-source. I'll try to have a look at it in the near future.. Regards, - David ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Devel] Re: [Fonts]Another approach to text in X
Dear David, - A text layout engine, based on UniType, supporting all kinds of sophisticated features (including OpenType, we haven't really touched GX for the lack of fonts to test and interest we ourselves have in the technology). May I humbly commend http://graphite.sil.org to you. Martin Hosken ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Another approach to text in X
On Sunday 23 December 2001 20:17, Keith Packard wrote: | Around 11 o'clock on Dec 23, David Turner wrote: | | But, it looks like UniType has some additional features: | - identify each installed/available face with a _unique_ | and _persistent_ 128-bit signature. | | This seems like it will be useful in transmitting precise face names from | one application to another, but I'm afraid that font versioning will make | it less useful in transmitting face names from one machine to another. | Is there some reason not to trust the font identification built into the | files as usefully unique? Hi Keith! You have mentioned that your solution is Independent of output technology or rasterization; it's just a configuration, customization and matching library How you deal with kerning in it? It's quite common in Publishing Industry when you update your AFM file (which complement PFB - PS Type1 font) say, once per year or even more often. Reason: new kerning values, or updated kerning values. It seems that you need to store Kerning information in each word processor document (when word processor, like KWord, operates in DTP mode, I am not speaking about plain text here) - even when you decided *do not embed* fonts. Reason: if you make font substitution, and change to another typeface, most likely all formatting information will be lost. Of course this should be stored in some XML format (like part of KWord document, or in XML with some completely new DTD) It would be nice to hear both from you and David Turner (and from Sun/Alan Coopersmith, of course) how transmitting face names will work and how you can prevent loosing of formatting info (missing kerning, tracking) in this case? It wil be very nice if text layouting font identification in X gets a boost (either with UniType, or with Keith's work, or with ST) but I am pretty much concerned how it wil affect (or improove) existing applications. | | My plan for 'fontconfig' was to use the names in the files and allow the | application to discover how close the requested pattern was to the actual | matched face. That way the application can discover whether the face | names and styles matched, or whether some substitution was made. | | * languages _really_ supported by the face (answering this | question is hard !!) | | I agree it's pretty hard, but I don't know if it's really needed. | Applications need to find a face which covers a reasonable portion of the | document, and then they need to find faces which can fill-in the missing | pieces, and which match the other faces reasonably well. Owen Taylor and | I talked about this at ALS and I think we've figured out a mechanism that | will work with upper level libraries in a reasonably efficient way. | | The idea is to list all of the available faces in 'match' order -- the | distance from the face to the requested pattern. Now this list can be How you are going to measure distance? It can be VERY difficult. And most likely this wil give platform-dependant results. There was discussion (I guees, on FT mailing list) about using HStem and VStem values for font identification, but IIRC several people were opposing this. Still I think that can be good, as it wil be inline with CSS3:Fonts module (where you can use HStem and VStem values for font matching) | searched to find a face containing any desired set of glyphs. Using a | persistant list built when the font was requested ensures that the order | is stable -- independent of the order in which glyphs are requested. | [...] | | Keith PackardXFree86 Core TeamCompaq Cambridge Research | Lab -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Another approach to text in X
Hi Vadim, Vadim Plessky a écrit : Hello All, I believe David Turner was working on similar project, or at least was planning to do this. He was planning to do both basic-text-layout engine (built on top of FT) and font-conversion module, IIRC. OK, first, I'm planning to work on this since I've made much design but written very little source for now (and the upcoming 2.0.6 FreeType release is currently taking most of my time).. My plan is/was to develop two distinct components: - a unified font type service for Unix, named UniType which has been more or less already described in Render mailing list. It's purpose is to provide capabilities that are either not possible or not implemented yet in something like libXft: - identify each installed/available face with a _unique_ and _persistent_ 128-bit signature. Each face id is independent of the locations and file names used/installed in the system but matches exact version of the files (and attachments, like *.pfa+*.afm). Sort of MD5 hashes in a more sophisticated way.. - provide an simple but efficient database implementation to associate custom keyed data to each Face ID. This will be used by UniType itself, but also available directly to applications if they need to build their own font catalog of course, you're free to use your own DB if you need it.. this persistent storage is the biggest feature in UniType, on top of that, many things can be built relatively easily: - storage of important font meta-data to avoid re-computing it each time one opens a face in FreeType (for example). Like: * languages _really_ supported by the face (answering this question is hard !!) * efficient charmaps that are automatically synthetized from the ones included in font files (for Type 1 fonts for example) * list of X11 encodings supported by each face (for backwards compatibility) * embedded versions of some fonts, to avoid re-generating them each time.. - management of system + user + application font list (through pattern matching similar to libXft, or even _directly_ through libXft) - automatically synthetized OpenType tables for certain faces (like GPOS tables to handle the kerning information found in Type 1 afm files in a more efficient way). One could also imagine being able to automatically create OpenType tables for certain - embedded versions of fonts, ready to be sub-setted for Postscript or PFT printing, for example.. another feature is the fact that UniType will not require applications to use FreeType (even if it will use it, and allow you to convert a Face ID into an input stream). This in order to be able to migrate to FreeType 3 when it comes out (in a _long_ future), or simply another font engine.. (that's a big difference with libXft that insists that you use FT2 for now). then: - A text layout engine, based on UniType, supporting all kinds of sophisticated features (including OpenType, we haven't really touched GX for the lack of fonts to test and interest we ourselves have in the technology). One of its biggest features is to provide an API similar to ATSUI, which uses styles instead of font attributes. This is actually the only way to properly deal with very subtle but sophisticated typographic processes without forcing the client application to know too much about font technology. The API looks like: - provide an array of 32-bit Unicode character codes (not UTF-16), called text - create one or more style objects and set their properties to features you need - apply styles to text runs (i.e. intervals to the text array) this is useful for several reasons, among which: - displaying internationalised text using several fonts for each script available. If you don't want to force the application to manually change the font attribute based on text's language fragments, you need to provide a virtual font capability (i.e. one logical font that embeds several different faces depending on scripts/languages). the problem with virtual fonts is that they're not really fonts, which makes your API somewhat limited (you cannot provide reliable metrics, OpenType tables, names, etc.. for them). - ever tried to display the euro sign correctly, when using a font that doesn't include its glyph ? The best way to do it is find a similarly-sized _and_ similarly-styled font that contain it and use that during text rendering. You generally don't want your applications to do that, so it's best left to the style object. -
Re: [Fonts]Another approach to text in X
Around 11 o'clock on Dec 23, David Turner wrote: - a unified font type service for Unix, named UniType which has been more or less already described in Render mailing list. I've split Xft into two pieces; one of which (fontconfig) sounds a lot like UniType: o Independent of output technology or rasterization; it's just a configuration, customization and matching library o Persistant database of existing fonts o API is independent of FreeType2, although the implmentation uses FreeType2 to examine new fonts o Precomputed meta-data, the most important piece being the set of encoded Unicode chars. But, it looks like UniType has some additional features: - identify each installed/available face with a _unique_ and _persistent_ 128-bit signature. This seems like it will be useful in transmitting precise face names from one application to another, but I'm afraid that font versioning will make it less useful in transmitting face names from one machine to another. Is there some reason not to trust the font identification built into the files as usefully unique? My plan for 'fontconfig' was to use the names in the files and allow the application to discover how close the requested pattern was to the actual matched face. That way the application can discover whether the face names and styles matched, or whether some substitution was made. * languages _really_ supported by the face (answering this question is hard !!) I agree it's pretty hard, but I don't know if it's really needed. Applications need to find a face which covers a reasonable portion of the document, and then they need to find faces which can fill-in the missing pieces, and which match the other faces reasonably well. Owen Taylor and I talked about this at ALS and I think we've figured out a mechanism that will work with upper level libraries in a reasonably efficient way. The idea is to list all of the available faces in 'match' order -- the distance from the face to the requested pattern. Now this list can be searched to find a face containing any desired set of glyphs. Using a persistant list built when the font was requested ensures that the order is stable -- independent of the order in which glyphs are requested. The reason a single synthetic face can't be exposed from the underlying font library is that a document containing passages from different locales may well want to use different faces for the same char, depending on the context that char is found (think Latin glyphs near Kanji embedded in a document that also has pure Latin passages). Obviously, a trivial synthetic face can be built from this list; simply search for the first face holding each glyph. I think we should push language support out of this library, at least for now, and focus on describing the Unicode coverage of the faces instead. * list of X11 encodings supported by each face (for backwards compatibility) Yuck. If applications really need this, let's make them support it themselves. * embedded versions of some fonts, to avoid re-generating them each time.. Hmm. I think this conflicts with your goal of being independent of the rasterizer. Also, target platforms which really need to avoid the CPU cost are also likely to have limited storage, making it unwise to keep large numbers of glyph images around. Perhaps we could consider caching rasterization efforts to share among multiple applications; that could be dynamically sized depending on the environment. The Render extension encourages this, I've just not bothered to use it as rasterization performance has not been a significant bottleneck. - management of system + user + application font list (through pattern matching similar to libXft, or even _directly_ through libXft) Any library we build will be used by Xft. Obviously, I'd prefer to use the Xft pattern code that I've moved to 'fontconfig', but I don't think it's too late to bail on that if we think it advisable. Opinions on whether the Xft pattern stuff could be improved are very welcome. (that's a big difference with libXft that insists that you use FT2 for now). With Xft split into two pieces, the underlying font configuration mechanism does not expose it's own use of FT for this same reason. Xft itself will always expose it's use of FT so that applications can get at the native FT API to access more sophisticated parts of that interface. then: - A text layout engine, based on UniType, supporting all kinds of sophisticated features (including OpenType, we haven't really touched GX for the lack of fonts to test and interest we ourselves have in the technology). Yes, keep this separate so that we can get on with solving the font configuration and customization issues. I don't think we can
Re: [Fonts]Another approach to text in X
On Friday 21 December 2001 01:41, Sergey Babkin wrote: | Alexander Gelfenbain wrote: |On Wed, Dec 19, 2001 at 07:20:45PM -0500, Sergey Babkin wrote: | Alan Coopersmith wrote: | 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 | | It would be good if it also could provide the output in PostScript. | |It would be capable of generating outlines. Converting them to |PostScript is trivial. | | I think, not quite trivial. I guess I should first explain that | I don't want to sound ungrateful, and the way it is now this | architecture looks very interesting and useful. Just it seems to me | that it's a great opportunity to fix the historical X's weakness | with printing. And seeing it missed once again would be a pity. | | Basically, rendering the general graphics in PostScript is easy | and does not require much effort. Rendering of the text is much | harder. The major thing making it complicated is the fonts. Of | course, transferring the outlines of a rendered page back is a | possible thing but it means large size of the resulting file and | slow rendering to bitmaps at the printer. Providing a way to convert | the used fonts to PostScript fonts, transferring them to the client | and then rendering the pages in terms of these fonts looks like a much | better thing. And probably provide a protocol to get the kerning | information on to the client (unless all the rendering including | kerning is done at the server side). | | Such a conversion is trivial too in the sense that it's clear | how it can be done, the only difficulty is to actually do it | and to provide an X protocol extension for such a transfer: Hello All, I believe David Turner was working on similar project, or at least was planning to do this. He was planning to do both basic-text-layout engine (built on top of FT) and font-conversion module, IIRC. [hope, David can clarify this] Most Linux projects use FreeType or technologies derivied from FreeType for font rendering. So it seems quire reasonable to me if we can listen to opinion of FreeType developers too, as well as developers of front-end, end-user products (KWord/KDE, in particular) Providing a way to convert the used fonts to PostScript fonts is indeed a quite important issue. I was discussing this (already some time ago) with guys from TrollTech (developers of QT) and KDE developers. At a moment, when you print from KDE application, data flow is coming in following way: KDE - QT - PostScript PostScript is later either converted to PDF (using ps2pdf from GhostScript) or printed/rasterized via Ghostscript (and its printer drivers) Font conversion (TrueType - PostScript) is happening in Qt library. Latest release of Qt, Qt3, allows either Font Embedding (via font conversion of TTF fonts or direct embedding of PS T1 fonts) or generating PS/PDf as is, without any fonts embedded (it's configurable). Project Alan Coopersmith was speaking about [Standard Type Services (ST)] is indeed looks quite interesting. But I am pretty much interested *how* it can be integrated into existing Linux/UNIX applications. Alan, do you cooperate in some way with TrollTech to ensure support for ST in QT library? I think this is somewhat critical for success of your project. I don't know wether your project, ST, overlap in some way with QT layouting capabilities or not. If QT is supported, that most KDE applications will be able to benefit form this immediately, at no extra cost (just as after RENDER extension introduction around 1 year ago) Another quite important question is support for SVG. You have mentioned that: It would be capable of generating outlines. Converting them to PostScript is trivial. Does it mean that converting outlines to SVG would also be trivial? Do you have that module already working? There is a (unconfirmed) opinion circulating around (off-list, of course...) that Adobe is going to scratch PostScript in favour of SVG somewhere in nearest future. Even if it's not the case, PDF is definitly getting higher priority in Adobe than PostScript, so I would say generating PDF, but not PostScript, from vector objects should be top prioroty for all projects related to layouting. So, what is the position of your project in relation to SVG and PDF? As you are employed by Sun
Re: [Fonts]Another approach to text in X
Alan Coopersmith wrote: 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 It would be good if it also could provide the output in PostScript. -SB ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Another approach to text in X
On Wed, Dec 19, 2001 at 07:20:45PM -0500, Sergey Babkin wrote: Alan Coopersmith wrote: 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 It would be good if it also could provide the output in PostScript. It would be capable of generating outlines. Converting them to PostScript is trivial. AG -- Alexander Gelfenbain, Sun Microsystems, Inc. +1 (408) 635-0612 ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
