Greetings, folks. This is a quick update on where things stand with the java2d-pstext project.
As seen from the bug reports, I have heard from folks with Asian locales on Solaris 8. They reported minor problems with the makefiles for the examples. I have created some revised makefiles to accomodate both Linux and Solaris, and should release them shortly. These will be among the first items to go into CVS.
I received a contribution of code for methods inherited from the Graphics abstract class. I was looking for a clean way to make Graphics usable without the weight of Graphics2D. (Potentially, this would be useful with JDK 1.1.8.) So far, I have not succeeded. Furthermore, the more I look, the more I am convinced that keeping compatibility with both 1.1.8 and 1.2 is too ambitious.
There are reports that JDK 1.3 will fix some of the problems that project tries to address. I have not been able to test JDK 1.3 to confirm this. The principal issue is how text is rendered, and whether it will actually specify and use a font instead of drawing glyph outlines.
Actually, if anyone has JDK 1.3 on Solaris or Linux, I'd be curious to know what results you get for PrinterJob. Try
make SimplePrint.test
in simple/Makefile, save to a file, and look at the generated PostScript code. Is it full of "curveto" and "lineto", or does it use "(...) show"?
So far, I do not expect Javasoft to accomodate CID fonts. I recently consulted with people who advised Javasoft on the matter perhaps a year ago, and felt it was safe to not support CID, until they ran into me. (I happen to help these folks generate PostScript for Asian locales.) The printers/publishers that I talk to want CID/Type1 for imagesetters or PDF with embedded CID. One of the motivations for the project is to produce Asian and multi-lingual PostScript that the printing industry will accept.
Thanks to those who have provided feedback so far.
--Rick Kwan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As java.awt.Graphics2D is an abstract class that extends java.awt.Graphics, it would be easy to write a PSGraphics2D that extends java.awt.Graphics2D... and by the way, it would extend java.awt.Graphics.
So what ?
This would make it possible to call (e.g.) java.awt.Component's paint (java.awt.Graphics) method - this is the way I pretend to use this PSGraphics2D object - and benefit from advanced 2D features in other contexts when necessary, without interefering.
Maybe I'm missing the reason why you see a compatibility problem ?
Hope this help,
-- javier
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the slow reply. I got sick earlier in the week...
Assuming that PSGraphics is a separate body of code, it would be nice to have PSGraphics2D inherit its work. But at the same time, PSGraphics2D conforms to Graphics2D, which is an abstract class, not an interface. What would be nice is
public PSGraphics implements Graphics { ... }
public PSGraphics2D extends PSGraphics implements Graphics2D { ... }
But this doesn't work because "implements" must refer to an interface, which Graphics2D isn't; it has some concrete methods in it.
I imagine the people who do framebuffers and other graphic devices must have faced this already, but I haven't figured out how they solved it.
--Rick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings, folks. This is a quick update on where things stand with the java2d-pstext project.
As seen from the bug reports, I have heard from folks with Asian locales on Solaris 8. They reported minor problems with the makefiles for the examples. I have created some revised makefiles to accomodate both Linux and Solaris, and should release them shortly. These will be among the first items to go into CVS.
I received a contribution of code for methods inherited from the Graphics abstract class. I was looking for a clean way to make Graphics usable without the weight of Graphics2D. (Potentially, this would be useful with JDK 1.1.8.) So far, I have not succeeded. Furthermore, the more I look, the more I am convinced that keeping compatibility with both 1.1.8 and 1.2 is too ambitious.
There are reports that JDK 1.3 will fix some of the problems that project tries to address. I have not been able to test JDK 1.3 to confirm this. The principal issue is how text is rendered, and whether it will actually specify and use a font instead of drawing glyph outlines.
Actually, if anyone has JDK 1.3 on Solaris or Linux, I'd be curious to know what results you get for PrinterJob. Try
make SimplePrint.test
in simple/Makefile, save to a file, and look at the generated PostScript code. Is it full of "curveto" and "lineto", or does it use "(...) show"?
So far, I do not expect Javasoft to accomodate CID fonts. I recently consulted with people who advised Javasoft on the matter perhaps a year ago, and felt it was safe to not support CID, until they ran into me. (I happen to help these folks generate PostScript for Asian locales.) The printers/publishers that I talk to want CID/Type1 for imagesetters or PDF with embedded CID. One of the motivations for the project is to produce Asian and multi-lingual PostScript that the printing industry will accept.
Thanks to those who have provided feedback so far.
--Rick Kwan
Hi,
As java.awt.Graphics2D is an abstract class that extends java.awt.Graphics, it would be easy to write a PSGraphics2D that extends java.awt.Graphics2D... and by the way, it would extend java.awt.Graphics.
So what ?
This would make it possible to call (e.g.) java.awt.Component's paint (java.awt.Graphics) method - this is the way I pretend to use this PSGraphics2D object - and benefit from advanced 2D features in other contexts when necessary, without interefering.
Maybe I'm missing the reason why you see a compatibility problem ?
Hope this help,
-- javier
Sorry for the slow reply. I got sick earlier in the week...
Assuming that PSGraphics is a separate body of code, it would be nice to have PSGraphics2D inherit its work. But at the same time, PSGraphics2D conforms to Graphics2D, which is an abstract class, not an interface. What would be nice is
public PSGraphics implements Graphics { ... }
public PSGraphics2D extends PSGraphics implements Graphics2D { ... }
But this doesn't work because "implements" must refer to an interface, which Graphics2D isn't; it has some concrete methods in it.
I imagine the people who do framebuffers and other graphic devices must have faced this already, but I haven't figured out how they solved it.
--Rick