Re: [JAVA2D] Too small page in case of Java Printing API.

[Phil Race]

The size you are seeing is in always user space coordinates.
If you examine the transform (Graphics2D.getTransform()) you'll see
that there's a scale from user coordinates to device resolution.
You'll also notice that line from 0,0 to 600, 480 fully crosses
the printable area of the page, showing that this is working properly.


-phil.

On Jun 26, 2009, at 6:03 AM, karlklin wrote:


Hello,

I have problem with resolution of printer using Java 2D Printing API.
Despite my printer has 600 x 600 DPI, inside
java.awt.print.Printable.print(Graphics, PageFormat, int) I receive  
page

format with 600 x 840 page size.

I have tried to set resolution using
javax.print.attribute.PrintRequestAttributeSet and
javax.print.attribute.standard.PrinterResolution, but with no result.

Can anybody solve this problem?

Regards,
Karl.   
--
View this message in context: 
http://www.nabble.com/Too-small-page-in-case-of-Java-Printing-API.-tp24219902p24219902.html
Sent from the Sun - Java2D-Interest mailing list archive at  
Nabble.com.


= 
= 
= 
= 
= 
==
To unsubscribe, send email to lists...@java.sun.com and include in  
the body
of the message signoff JAVA2D-INTEREST.  For general help, send  
email to

lists...@java.sun.com and include in the body of the message help.


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] Native font rasterization in JDK 7

[Phil Race]

It has been in JDK7 for a long time. Since b28 according to the bug  
database.


-phil.

On May 3, 2009, at 2:40 PM, jav...@javadesktop.org wrote:

Just downloaded the latest b57 of JDK 7, and it looks like the  
native font rasterizer (for Windows) has not been forward ported. Is  
this correct? If this is indeed so, are there plans to do the port  
in the near future?


Thanks
Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=344784

= 
= 
= 
= 
= 
==
To unsubscribe, send email to lists...@java.sun.com and include in  
the body
of the message signoff JAVA2D-INTEREST.  For general help, send  
email to

lists...@java.sun.com and include in the body of the message help.


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] Problem in printing on specfic printer on network

[Phil Race]

You are probably right that the printer doesn't recognise the contents.

DocFlavor.BYTE_ARRAY.AUTOSENSE is really no more than a way
to send a stream of bytes to your printer. If the byte stream
is a Postscript document (for example) and the printer is a PCL-only
printer then its just never going to work. Nothing we can do will
ever change that. The onus is on you to only send that content to
a device that understands it, or to first convert it into that format.

But you should consider *why* you are using AUTOSENSE at all?
That's bypassing Java and Windows printer-independent rendering.

Graphics.drawString(...) via a PrinterJob will work on any device

The listener methods presently will not tell you anything more
than the JDK internally completed sending data to the print spooler.
It will not tell you anything about whether the printing on the
device really worked. 


-phil.


jav...@javadesktop.org wrote:

Hi Jennifer

Sorry I wrongly wrote it is not printString it is printContent, so now I edited 
it. I am trying your suggestion but I think so the problem that my doc favor is 
not recognized by printer. When I debugged my program execution goes to the 
printDataTransferCompleted() and then printJobNoMoreEvents() methods of 
PrintJobListener interface but string is not getting printed. I have HP 
laserjet as my network printer.

Thanks for your help
Shashwat
[Message sent by forum member 'shashwat_anand' (shashwat_anand)]

http://forums.java.net/jive/thread.jspa?messageID=334130

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.
  


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] Scaling of print-out incorrect with non-default printer resolutions

[Phil Race]

First, I'm assuming you've made absolutely sure this is the fix for your 
problem.
I'm not sure I'll have the cycles but I'll see if I get can someone to 
backport it.
But its getting tighter to justify changes in the 6 updates and this has 
garnered

very few votes.  I think a business case might help, where a business case
doesn't mean why you want it, but what the return is on the time we spend
backporting it. A support contract would help greatly.

-phil.

jav...@javadesktop.org wrote:

Short description of the problem:
When the user opens the PrintDialog and selects a non-default printer resolution from the 
printer preferences and clicks print, the print-out comes out too small or 
too large (depends on the resolution that is set by the user).

A bug report already exists for the problem described above. [b]Bug-ID: 
6357932[/b]
And the bug seems to be fixed for release 7 of Java.

My question is:
[b]Is it possible, that this bug-fix is incorporated into one of the next 
actual releases of Java_6?[/b]


Why is this so important for me and hopefully for other java developers:
I'm developing a software for creating and printing high quality print-outs. 
Accurate printing results are essential for software with the intention to 
create print products. The software is useless when everything works fine but 
the end result is disappointing.

Here is a scenario, which shows the importance of the problem: 


The target group for the software is made up of private individuals, whose 
printers by default are configured for printing on normal A4 paper with a 
normal resolution(300dpi-600dpi). This is the default configuration for the 
majority of users.
Now the user starts the software and creates some documents for printing on high quality glossy photo paper. 
He clicks on the print button and the native print dialog comes up. The user clicks on the printer 
preferences and selects e.g. High glossy photo paper. He could also change the print quality from 
normal to high. He confirms his actions and clicks print on the print dialog.
The result is: The print out will be scaled wrong, because the resolution of the printer has changed to an non-default resolution. 


A compromise could be:
The user opens the systems control panel and changes the printers default configuration. But this is unacceptable for the target group described above. You cannot expect to go to the system control panel and change the printers default configuration every time the user wants to use this software. In general printing with high resolutions is rarely used by the most users. This is the reason, why the default resolution for most people is normal or medium resolution. 



[b]What are the odds that the bug-fix mentioned above is being integrated into 
the current Java_6 release? This is very important for me, because the 
existence of my software project depends on the fixing of this bug.[/b]

Best regards
Metin E.

[i]Operating System: Windows XP SP3
JDK Version: 1.6.0_12
Printer: The bug is printer-independent (tested on various printer-models)[/i]
[Message sent by forum member 'nitem' (nitem)]

http://forums.java.net/jive/thread.jspa?messageID=330907

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.
  


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?

[Phil Race]

Chris Campbell wrote:


No, the DirectDraw pipeline no longer exists as of JDK 6u10.  If the 
D3D pipeline is disabled (or can't be enabled due to driver/hardware 
problems) we switch back to using GDI for onscreen rendering, and 
VolatileImages/BufferStrategy then become backed by system memory 
surfaces (analogous to BufferedImages, which implies software rendering).


By way of clarification, this is because the old DX7 and D3D 9 APIs are 
different and you can't

use both, so we had no choice.



2) 6u10 added native font rendering to Java. When is this enabled? Is 
it always used in all pipelines or just in the D3D rendering?




I'll leave this one for Phil or Igor. 


Its implemented in a manner independent of pipelines. It wouldn't have 
been worthwhile
to do it in a way that only worked on some surfaces, or that was sucky 
slow for them.


-phil.

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?

[Phil Race]

2) 6u10 added native font rendering to Java. When is this enabled? 
Is it always used in all pipelines or just in the D3D rendering?




Its implemented in a manner independent of pipelines. It wouldn't have 
been worthwhile
to do it in a way that only worked on some surfaces, or that was sucky 
slow for them.


In case that wasn't 100% clear ..

As of 6u10, on Windows only, the native system is used to rasterize LCD 
glyphs and we
store these in our regular internal glyph cache. So its completely 
independent of the final blitting step.
So you'll get the natively renderered glyphs regardless of what kind of 
Java2D surface you're rendering to
(whether it is a BufferedImage, a VolatileImage, a BufferStrategy, etc) 
or what rendering pipeline
is currently in use (D3D, OGL, GDI, software, etc). 
The sole exception to this is the glyphs from fonts that are in the 
jre/lib/fonts directory - ie the fonts

that ship with Java. For the Windows JRE this means Lucida Sans Regular.

-phil.

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] Exactly which graphics surfaces get HW accelerated?

[Phil Race]

The question is where the native rasterisation is used vs where
the Java rasteriser is used. We don't use LCD rasterisation of
either flavour in such cases.
There are also limitations to where Microsoft can or do apply cleartype.
I've seen it in the distant past although I can't say for certain if
it was  the circumstances described/discussed here (transforms):
http://blogs.msdn.com/ie/archive/2006/08/31/730887.aspx
..
and here (intermediate surfaces) in a posting by a MS WPF engineer :
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/a2f093ca-267c-4af2-b35e-13c01eb4854b/

there are indeed some challenging technical problems behind enabling ClearType 
on intermediate surfaces.

Basically, the fundamental problem is that ClearType needs a separate alpha 
value
for each of the three color channels (RGB or BGR in common LCD configurations),
and typical intermediate surface formats such as ARGB or PARGB have only one.

We were able to get around this issue in some cases for WPF V1,
however this wasn't possible for text rendered onto semi-transparent
intermediate surfaces, which are often used to achieve shadow-like effects.
We have received customer feedback similar to yours on this limitation before,
and we are looking into ways to solve it in future.


-phil.


jav...@javadesktop.org wrote:

The sole exception to this is the glyphs from fonts
that are in the 
jre/lib/fonts directory - ie the fonts

that ship with Java. For the Windows JRE this means
Lucida Sans Regular.


There is another, much bigger exception - painting texts on translucent surfaces 
(when the current SrcOver composite has alpha  1.0) uses the bundled 
rasterizer, which is inferior as far as Segoe UI font (default Vista) is concerned.

Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=330617

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] Sub-pixel text antialiasing on soft surfaces not possible under 6u12?

[Phil Race]

It never was possible. In some cases we incorrectly allowed it to happen 
and the results were incorrect.
That loophole was closed and there's an open RFE to support it 
http://bugs.sun.com/view_bug.do?bug_id=6749069


-phil.

jav...@javadesktop.org wrote:

Hi Igor,

I forgot to mention that I am talking about non-opaque buffered images.  I 
believe that it's not possible to achieve sub-pixel antialiasing with such 
buffers anymore.  Is this correct?

  


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] Printing JPanel contents...

[Phil Race]

If a Component doesn't know how to paint itself, then its going
to be pretty tricky getting it to paint on demand to the screen
as well as the printer.
JPanel is a container. Maybe you didn't get its children painted.
Did you try java.awt.Component.printAll(Graphics g) ?

-phil.

jav...@javadesktop.org wrote:

Hi All,

I have a special case where there is a library such as JDIC that draws directly 
to a component. Instead of using the print capabilities of the browser via 
javascript I want to print what is on the JPanel. I also want to do the same 
thing for other type of heavyweight components. I noticed if I used 
createImage(l,w) then direct the output to a BufferedImage it only gives what 
looks like the background color.

I have not seen very many examples where you capture a JPanel or other 
components where you start with the panel and not a file whose contents load 
into the panel.

Seems like printing will be an issue for JavaFX with this mixing of components 
heavyweight/lightweight so I am hoping I can get an answer here since quite a 
few Java2D people worked on JavaFX and printing might have been discussed for 
the fancy images and other unique visual imagery it was designed to handle.

As a last resort I used the awt Robot and that sort of worked but it is a 
screen capture solution not the type I really want when printing an image that 
might be bigger than the component.

Thanks,
-Tony
[Message sent by forum member 'tdanecito' (tdanecito)]

http://forums.java.net/jive/thread.jspa?messageID=328251

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] Clipboard, print, and Save-to-jpeg problem

[Phil Race]

The code below gives no indication of what could cause
intermittent problems.

If its a problem in both copying to the clipboard and
printing its seems likely to be a general bug in your code.

I guess you are drawing to an image.
Perhaps you have an inappropriate use of multiple threads
and you are using the image before rendering is complete.

-phil.


Olsen Chris wrote:

Hello All --

  I am experiencing a vexing problem trying to send contents of a
Component to the clipboard, printer, or save-to-jpeg.  All of my
procedures use the drawPage method below to send the graphs to the
targets.  I have been able to successfully get contents to each of these
targets, but a problem intermittently occurs; that is it occurs with
some graphs and not with others.  Sometimes the text (using drawString)
gets lost on the way to the clipboard, printer, and save-to-jpeg,
leaving a textless graph.

  In some cases simply rearranging the calls (e.g. drawStrings performed
after other graphics) is successful, and other times no.  I have
included what I hope is representative code.  The drawStringInfo
basically draws text, and the drawHorizScale basically draws lines.

  I feel there must be some general principle in the painting (or
wherever) that I'm not understanding.  All my graphs get to the screen
w/o problem one!  Does this problem ring a bell with anyone?  (And, more
importantly, does a solution come with the ringing??)

  Thank you in advance for any help, and thanks to all those I have
learned so much from as I lurk...

-

public void drawPage(Graphics2D g2)
   {
  g2.setFont(new Font(Monospaced, Font.BOLD, 12));
  drawHorizScale(g2);
  drawStringInfo(g2);   
   }
  
private void drawStringInfo(Graphics2D g2)
   {  
  g2.drawString(Bldg =  + bldgName, 10, 20);

  g2.drawString(Tchr =  + tchrName, 10, 35);
  g2.drawString(Item Statistics, 50, 50);
  g2.drawString(***   p-Values vs. Building Residuals   ***, 380,
50); 
  g2.drawString(Itm   BRes   pVal, 15, 100);

  g2.drawString(Itm   BRes   pVal, 160, 100);
  g2.drawString(Building Residual, 500, 580);
  return;
   }


public void drawHorizScale(Graphics2D g2)
  {
 g2.drawLine(smallExtent, horizLineLevel, largeExtent,

horizLineLevel);
   
 //   Draw small x ticks  
 for (double hMark = startPrintScale; hMark  stopPrintScale; hMark

= hMark + smallTickInterval)
 {
if ((loEndOfScale = hMark)  (hMark = hiEndOfScale))
{
   int screenXCoord = getScreenX(hMark);   
   g2.drawLine(screenXCoord, horizLineLevel, screenXCoord,

horizLineLevel + 5);
}
 } 
}


-

  -- Chris

Chris Olsen
Assessment Facilitator
Cedar Rapids Community Schools
1243 20th St. SW
Cedar Rapids, IA 52404

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] How to print a multipage PDF or PostScript?

[Phil Race]

jav...@javadesktop.org wrote:
Hi, (please pardon my english i'm coming from France) 

I'm working on a method which will allow me to produce PDF or PostScript files which contain multiple images (jpeg or png). 
  


Whilst we caa generate PS directly, PDF will only be possible if you 
have a driver that does it.

I would like to one image per page in one document. I succeeded in printing one 
image one page, but i can't add new pages in the same document.

How could i do that?
  


You will need to create a PrinterJob, load the images using 
javax.imageio.ImageIO into
a java.awt.image.BufferedImage, and then print from a 
java.awt.print.Printable,
rendering the images using Graphics2d.drawImage(..) exactly where you 
want on the page.

I use the following properties with my PrintRequestAttributeSet object:

[i]MediaSizeName.ISO_A4

MultipleDocumentHandling.SINGLE_DOCUMENT_NEW_SHEET

Finishings.STAPLE[/i]
  


Neither of these lasst two are supported in the Sun implementations.
Its possible Finishings may be supported by CUPS, if you have a printer 
that does it,

but we don't have IPP on windows.

-phil.



And about the code:

Doc doc = new SimpleDoc(fis, flavor, null);   // fis: my file input stream
pj.print(doc, aset);  // aset: my 
PrintRequestAttributeSet object


Do i need to create a new PrinterJob?

Thank you,

Val
[Message sent by forum member 'mofx71' (mofx71)]

http://forums.java.net/jive/thread.jspa?messageID=322771

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.
  


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] Datacard SP25 Plus and Java Printing

[Phil Race]

This came up once before and my analysis at that time was that
the printer driver for these DataCard SPX5 printers is buggy.
http://bugs.sun.com/view_bug.do?bug_id=5095586
Read my complaints about the driver there.
Maybe there's an updated driver available?

-phil.

[EMAIL PROTECTED] wrote:

Hi,

We are working on implementing ID-Card printing solution for our customer using 
Datacard SP25 Plus and Java Printing.

We do have the following Problem:

The default and the only MediaSize for this printer is CR80 (2.13 x 3.88 
inches).

When printed from any program using Windows service (for e.g Wordpad), it shows 
the correct Media Size.

When trying to print via Java method, some arbitrary Media Size is shown. And 
it varies from PC to PC.

How to fix this problem? How to implement or create custom class for this 
MediaSize?

Here is the Java Testing Code.


import java.awt.GraphicsConfiguration;

import javax.print.DocFlavor;
import javax.print.PrintService;
import javax.print.PrintServiceLookup;
import javax.print.ServiceUI;
import javax.print.attribute.HashPrintRequestAttributeSet;
import javax.print.attribute.PrintRequestAttributeSet;
import javax.print.attribute.standard.MediaPrintableArea;
import javax.print.attribute.standard.MediaSize;

public class TestDatacardSP25 {

public static void main(String[] args) {
PrintService[] services = PrintServiceLookup.lookupPrintServices(null,
null);

PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet();
//  Media size
aset.add(MediaSize
.findMedia((float) 2.13, (float) 3.38, MediaSize.INCH));
//Media printable area
aset.add(new MediaPrintableArea(0, 0, (float) 2.13, (float) 3.38,
MediaPrintableArea.INCH));

PrintService service = PrintServiceLookup.lookupDefaultPrintService();
DocFlavor flavor = DocFlavor.INPUT_STREAM.AUTOSENSE;
//Show print Dialog
service = ServiceUI.printDialog((GraphicsConfiguration) null, 60, 60,
services, service, null, aset);
}
}


Thank You.
[Message sent by forum member 'mp_prabu' (mp_prabu)]

http://forums.java.net/jive/thread.jspa?messageID=320790

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Print BufferedImage Externally Generated

[Phil Race]

[EMAIL PROTECTED] wrote:

Thanks for your help Phil.


But

I'm trying to build up a BufferedImage using its
 Graphics component, 
nd then print that image using a Printable

Why? As in I don't know why you aren't rendering
directly to the printer ?


I have a builder for my non-print documents, but it seems that I can't 

 apply the normal builder to a printer document because of the way java print 
services works.
 If I were to apply the builder directly to the printer, it seems that I would 
have to somehow
  enter the print method in the builder and then have the director call the 
builder while it was
 in the print method, but that's not possible.  So instead, I'm trying to 
build an image and pass
 it to the printable.  But as you have pointed out, this is not a nice 
solution.  Any advice?

Consider that the rendering process first needs to obtain a Graphics instance, 
either
from BufferedImage.createGraphics() or the one passed in to Printable.print(..).
I cannot see why your builder should know or care what the origin is, nor do 
I see
why you can't call your builder's paint method from print().

-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Print BufferedImage Externally Generated

[Phil Race]

The clipping is because the imageable area of the paper may be less than 
the physical size of the paper.
You need to get the imageable area from the PageFormat and then scale 
your rendering (ie the final image) to fit.
You can also control this by specifying the imageable area in the 
PageFormat but you'll need to use the javax.print

APIs to find out what is the hard liimit for the device
See 
http://java.sun.com/javase/6/docs/api/javax/print/attribute/standard/MediaPrintableArea.html


But
I'm trying to build up a BufferedImage using its Graphics component, 
and then print that image using a Printable

Why? As in I don't know why you aren't rendering directly to the printer ?

If you do what you are doing you will get blocky output, unless you 
create a very large image and scale
it to printer resolutions. Even then it means you won't get printer 
fonts etc.


So I suspect your approach is costing you in
- output quality
- memory used
- performance

-phil.

[EMAIL PROTECTED] wrote:

Hi, I'm trying to build up a BufferedImage using its Graphics component, and 
then print that image using a Printable.  The problem is that some of my 
operations on the graphics component seem to be lost, and when I print the 
image, a lot of it is clipped off around the borders.  The code below shows the 
gist of what I'm doing.

// this method is in class A
foo(String text, Font font, B b, int x, int y) {
  Graphics2D g2d = (Graphics2D) image.getGraphics();
  g2d.setColor(Color.black);  // this color gets lost when bar is called
  g2d.setFont(font); // this font gets lost when bar is called
  b.bar(text, x, y);
}

// this method is in class B
bar(String text, int x, int y) {
  Graphics2D g2d = (Graphics2D) image.getGraphics();
  g2d.drawString(text, x, y); // this does not get lost when the image is 
printed
}

// this is the print method for the Printable, the image is passed to the 
Printable
print(Graphics g, PageFormat pf, int pageIndex) {
  if (pageIndex == 0) {
Graphics2D g2d = (Graphics2D)image.getGraphics();
g2d.translate(pf.getImageableX(), pf.getImageableY());
((Graphics2D)graphics).drawImage(image, null, 0, 0);
return Printable.PAGE_EXISTS;
  } else {
return Printable.NO_SUCH_PAGE;
  }
}


If I hardcode the color and font in the bar method, then the text actually comes out at the 
printer, but if x  80 or x  500, it doesn't get printed; same if y  80 or y 
 600 (these are approximate, I'm just estimating based on what I printed and where it 
got cut off).  This leaves about a 1 inch margin around the printed text on the paper from 
the printer.  Ultimately, I want to generate a document image using j2d and send that to 
the printer.  Any help is greatly appreciated!

Thanks in advance!
[Message sent by forum member 'wtrpirate' (wtrpirate)]

http://forums.java.net/jive/thread.jspa?messageID=318909

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
  


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Looking for very high-quality text rendering library

[Phil Race]

If you are looking for something that will be used by Sun's implementation of
Graphics.drawString, then since there's no way to hook in to that, there
won't be such a solution.

So I guess you are looking for something that's going to amount to another
implementation of Graphics2D and which happens to have text rendering properties
that coincide with the subjective notion of when text looks high quality.
Sounds to me like a tall order.

-phil.

[EMAIL PROTECTED] wrote:
With the coming of 6u10, text on Java apps looks the best it ever has (at least in Windows). 
Taking advantage of native font rendering was a really good idea (with a nice 
speed/quality balance)

, and it's a big step forward for Swing apps.

But, when I look closely, the way Windows renders text grates on me like 
fingernails on a
blackboard, particularly larger fonts which [i]should[/i] look great, but end 
up looking cheesy.

Does there exist out there a java text-rendering library which could yield 
really great

 text rendering, at least for header/subheader text?  I'd be willing to 
sacrifice speed
 for higher quality--Speed is less of a consideration than it would be for a 
general-purpose
 text rendering solution, as the 'display' headings are not incredibly dynamic (i.e., 
don't

 change all that often, but often enough that I can't just resort to using
Photoshop-generated/static images).


I would really appreciate any input on this.
[Message sent by forum member 'mmuday' (mmuday)]

http://forums.java.net/jive/thread.jspa?messageID=300576

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Native text rasterizer and translucent graphics

[Phil Race]

No, the only thing that has actually been fixed to date in 6u10 is
6728834: D3D/OGL: LCD AA text becomes bold and blurred when rendering to a non-opaque 
destination


which fixes where the D3D renderer was not backing off to greyscale,
and that caused bad artifacts.

6749060 :LCD AA text rendered incorrectly when destination is non opaque (sw 
pipeline only)

was filed yesterday when Dmitri worked out that the software pipeline was 
causing
similar artifacts.

6749069 is an RFE to add support for these cases in the pipelines,
which I think is what you really want, but that's for the future.

-phil.

[EMAIL PROTECTED] wrote:

Phil,

Allow me to reopen this discussion. It looks like there are a lot of bug 
reports being marked as fixed and those reports sound very similar to the

question that i had on Windows native rasterizer and translucent composites.
Specifically, i saw 6749069, 6728834 and 6749060. Has this limitation been
revisited? Does b32 (or the final planned 6u10) use native rasterizer for
translucent target destination?


Thanks
Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=299669

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Is there a RenderingHint for ClearType/SubPixel rendering?

[Phil Race]

[EMAIL PROTECTED] wrote:

Sorry, a few small corrections :) I forgot to account for the fact that the 
desktop might support ClearType rendering but the user disabled them.

KEY_TEXT_ANTI_ALIASING:

DEFAULT: Anti-aliasing is on for JDK 1.6 if desktop anti-aliasing is enabled, 
OFF for JDK 1.5
  


It may not be clear to others - or perhaps you- but your comments above 
refer to *Swing* behaviours. Not 2D.

2D's default on all (Sun) implementations to date is OFF.

And for 1.5 there was no code in AWT for Swing to use to pick up desktop 
properties.
Its all new in 1.6 - if you can call 1.6 new anymore, since its been out 
for almost 2 years.

ON: Anti-aliasing is on, using whatever algorithm is preferred by the desktop. 
If the desktop anti-aliasing is disabled this falls back on JDK rendering.
  
Wrong. the rendering hint value ON means greyscale AA. It does not 
mean desktop default.
And on windows ON is not going to correspond to any windows desktop 
setting.
For windows its either OFF, GASP (== windows standard), or 
LCD_HRGB(~=cleartype)

[Message sent by forum member 'cowwoc' (cowwoc)]
  


-phil.


http://forums.java.net/jive/thread.jspa?messageID=297469

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
  


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Is there a RenderingHint for ClearType/SubPixel rendering?

[Phil Race]

[EMAIL PROTECTED] wrote:


Why couldn't ON (from Java 1.2) mean grayscale AA up to 1.5 and in 1.6 become 
general AA? Isn't that a superset? Could it really break any practical form of 
backwards compatibility?
  


It would be an incompatible change.
And what would 2D pick when you did say ON? greyscale is the closest 
thing to general AA anyway.

And what would you then specify to get what previously meant ON?

If you want something new, then use a new value. Think of it another 
way: ON should perhaps have

been named GREYSCALE.

So all this was carefully considered long ago, and the implemented 
behaviour seems the safest way forward.


-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Should drawGlyphVector() honour rendering hints?

[Phil Race]

[EMAIL PROTECTED] wrote:

Should the drawGlyphVector() method in Graphics2D honour any current rendering 
hints such as RenderingHints.KEY_TEXT_ANTIALIASING?  It appears not to be doing 
this.

  
It gets that particular hint from the FontRenderContext that is used to 
create/layout the GlyphVector.


-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Taking advantage of printer's native resolution

[Phil Race]

In the print() method look at the graphics transform and scale down 
accordingly.


Eg if the printer is 360 dpi, then the transform will report a scale of 
(5,5) so you need

to apply a user scale of 1/5, 1/5.

Then a 1 pixel user space line will be 1 device pixel.

FYI  printers that say they are 2400 dpi are not necessarily truely that 
fine so it may not

be that a line is 1/2400 but that's a matter for the printer vendor.

-phil.

[EMAIL PROTECTED] wrote:

Since I have not received an answer to my previous question, I will try to 
simplify it even further.

For an arbitrary printer, how can I print a single line that is one printer dot wide by N dots long, ie, print the finest line the printer is capable of printing? 


For a 300dpi printer this line would be a line 1/300 wide. For a 2400dpi printer 
this would be a line 1/2400 wide, etc.

Thanks!
[Message sent by forum member 'robross' (robross)]

http://forums.java.net/jive/thread.jspa?messageID=287172

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
  


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Querying paper sizes for a printer

[Phil Race]

You almost had it. For some reason you aren't properly using the answer 
(Object [] res)  you got from the service,
so you are only seeing the first of the list. And I'm not sure where you 
got MediaRequested from, that

should not compile as there's no such class.

That should be
Media[] res = (Media[])getSupportedAttributeValues(Media.class, null, 
null);


Then print each of the elements of res.

-phil.

ssinai wrote:

Given a print service from something like

PrintService defaultPrintService =
PrintServiceLookup.lookupDefaultPrintService()

is there a way to query the default print service to get the paper sizes
that print service (printer) can handle?  For example, I'd like to get a
list back containing things like Legal, Letter, A4, A5, B4, etc.

I'm fiddling around with the following code...

PrintService defaultPrintService =
PrintServiceLookup.lookupDefaultPrintService();
Object [] res = (Object
[])defaultPrintService.getSupportedAttributeValues(Media.class, null, null);
MediaRequested mr = (MediaRequested)res[0];
System.out.println(mr=+mr);

and the final result is mr=na-letter.

I was hoping I'd get a list of legal paper sizes.   Is this even possible?

Thanks.
  


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] DocPrintJob doesn' work with Zebra printer

[Phil Race]

Sending the raw bytes of a PDF file to a printer will work only if the 
printer itself can interpret PDF.

I'd be surprised if this ZDesigner LP 2824 is capable of this.

https://www.cdw.com/shop/products/default.aspx?EDC=1444344

-phil.


[EMAIL PROTECTED] wrote:

Hi, here's my problem.
My aim is printing a PDF file by DocPrintJob, instead of PrintJob and Printable 
class. Here's a code fragment:

[..]
DocFlavor flavor = DocFlavor.BYTE_ARRAY.AUTOSENSE;
HashPrintServiceAttributeSet serviceAttributeSet = new 
HashPrintServiceAttributeSet();
PrintService[] printServices = 
PrintServiceLookup.lookupPrintServices(flavor, serviceAttributeSet);
for (int i = 0; i  printServices.length; i++) {
String printerName = printServices[i].getName();
if(MYPRINTER.equals(printerName)) { 
//found!!
PrintService printService = printServices[i];
DocPrintJob docPrintJob = 
printService.createPrintJob();
docPrintJob.addPrintJobListener(new 
PrintJobAdapter() {

public void 
printDataTransferCompleted(PrintJobEvent e) {
System.out.println(Document sent to 
printer.);
}
public void 
printJobCompleted(PrintJobEvent e) {
System.out.println(Document was 
successfully printed.);
}
public void 
printJobCancelled(PrintJobEvent e) {
System.out.println(Document 
printing was cancelled.);
}
public void 
printJobFailed(PrintJobEvent e){
System.out.println(Document failed 
to print.);
}
public void 
printJobNoMoreEvents(PrintJobEvent e) {
System.out.println(No more print 
events.);
}
public void 
printJobRequiresAttention(PrintJobEvent e) {
System.out.println(Printer requires 
attention.);
}   
}
);
File f = new File(PDFFILE);
byte[] bytesFromFile = getBytesFromFile(f);
SimpleDoc doc = new SimpleDoc(bytesFromFile, 
flavor, null);
PrintRequestAttributeSet reqAttributeSet = new 
HashPrintRequestAttributeSet();
reqAttributeSet.add(new MediaPrintableArea(0f, 
0f, 1.85f, 1.1f, MediaPrintableArea.INCH));
reqAttributeSet.add(new Copies(1)); 
docPrintJob.print(doc, reqAttributeSet);
[..]

where MYPRINTER is the target printer name (at the moment, ZDesigner LP 2824).
When code is executed, the standard output displays

   Document sent to printer.
   No more print events.

i.e., a [i]printDataTransferCompleted(e)[/i] and a 
[i]printJobNoMoreEvents(e)[/i] is fired to the anonymous PrintJobListener.
But the printer doesn't print (neither a blank page).

Changing the target printer name (i.e., using another printer, an HP Laser 
Jet), all works fine.

Why?

Matteo
[Message sent by forum member 'matteoforesti' (matteoforesti)]

http://forums.java.net/jive/thread.jspa?messageID=282755

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
  


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Performance regression in 6u10 b22

[Phil Race]

   Then it is likely caused by this fix, although I don't
   quote see how
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308

We did a bit of testing and one necessary correctness change
in this bug fix was made in SrcOver software blit and fill loops.
ie I know exactly which line of code makes the performance
change come and go in your app, but its not something we can undo.

The strange part of it is that the change is just a compile time
macro so that for opaque destinations, there should be no runtime cost.
ie logically if anything it should lead to less work, not more.
And for non-opaque destinations, it should be exactly as it was before.

Not sure why it affects your app - we couldn't make it show up
any of the tests in J2DBench2. Either the Microsoft compiler
is doing something that adversely affects the generated code,
or perhaps the different results in the opaque dest case cause
more work to be needed, but it seemed likely you were hitting
the first case.

-phil.

Dmitri Trembovetski wrote:

[EMAIL PROTECTED] wrote:

Hi, Dmitri

The output of trace_level:

[I] OS Version = OS_VISTA or newer
[E] D3DPPLM::CheckForBadHardware: found matching hardware: 
VendorId=0x8086 DeviceId=0x

[E] D3DPPLM::CheckForBadHardware: bad hardware found, device disabled
[E] D3DPPLM::GDICheckForBadHardware: no suitable devices found


  OK, you have an Intel chip. The d3d pipeline is
  disabled for all Intel boards so the regression
  is probably not related to the d3d changes in this
  build.

  Then it is likely caused by this fix, although I don't
  quote see how
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679308

  Does your code render to translucent images much?


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Native text rasterizer and translucent graphics

[Phil Race]

The first line is LCD text, the second line is greyscale.
The problem is that we do not have loops - in either software
or hardware, that work for LCD text with the composite you have specified.
There's an open bug on this: 6274808.

-phil.


[EMAIL PROTECTED] wrote:

Reposting from Swing  AWT forum since it was suggested that this is a better 
place.

It looks like the new native text rasterizer is not used when the current 
graphics composite is translucent. Here is the test app that i'm running on 
Vista SP1 with 6u10 b14:

[code]
package test;
 
import java.awt.*;

import java.util.*;
 
import javax.swing.*;
 
public class TextRenderingPanel extends JPanel {
 
	private static Map desktopHints(Graphics2D g2) {

Toolkit toolkit = Toolkit.getDefaultToolkit();
GraphicsDevice device = g2.getDeviceConfiguration().getDevice();
Map desktopHints = (Map) toolkit
.getDesktopProperty(awt.font.desktophints);
// It is possible to get a non-empty map but with disabled AA.
if (desktopHints != null) {
Object aaHint = desktopHints

.get(RenderingHints.KEY_TEXT_ANTIALIASING);
if ((aaHint == RenderingHints.VALUE_TEXT_ANTIALIAS_OFF)
|| (aaHint == 
RenderingHints.VALUE_TEXT_ANTIALIAS_DEFAULT)) {
desktopHints = null;
}
}
return desktopHints;
}
 
	@Override

protected void paintComponent(Graphics g) {
Graphics2D g2d = (Graphics2D) g.create();

Map desktopHints = desktopHints(g2d);
if (desktopHints != null  !desktopHints.isEmpty()) {
g2d.addRenderingHints(desktopHints);
}

g2d.setColor(Color.white);
g2d.fillRect(0, 0, getWidth(), getHeight());
g2d.setColor(Color.black);
g2d.setFont(new Font(Segoe UI, Font.PLAIN, 12));
g2d.drawString(Text rendering, 10, 30);
g2d.setComposite(AlphaComposite.SrcOver.derive(0.5f));
workaroundBug6576507(g2d);
g2d.drawString(Text rendering, 10, 60);
g2d.dispose();
}

public static void workaroundBug6576507(Graphics graphics) {
Font font = graphics.getFont();
font = font.deriveFont(font.getStyle(), font.getSize2D());
graphics.setFont(font);
}
 
 
	public static void main(String[] args) {

SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
JFrame frame = new JFrame(Text rendering);
frame.add(new TextRenderingPanel(), 
BorderLayout.CENTER);
frame.setSize(300, 200);

frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
});
}
 
}

[/code]


Running this you can see that the 'e's on the second line of text do not come 
from the same rasterizer as the 'e's on the first line of text. Is this the 
expected result, and if so, would i have to create a temporary image, render 
the full-opacity text there and then render that image back (with translucency) 
to get consistent rendering?

Note that I have to use deriveFont as the workaround for bug 6576507 as 
suggested in [1]. Doesn't look like the fix in JDK 7 was backported to 6u10.

Last thing - letter 'g' is one pixel narrower than in the real native 
rendering (from the title pane of the same frame).

Thanks
Kirill 


[1] http://forums.java.net/jive/thread.jspa?threadID=28226
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=268874

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

[JAVA2D] JDK 6u10 beta is out.

[Phil Race]

JDK 6 u10 beta is now live on java.sun.com (see the main page for a link)
Although we'll continue to put out regular weekly builds as we fix bugs,
this is feature complete and has been through a full testing cycle.

If you haven't tried 6u10 recently, please do so now and file issues at
bugs.sun.com

For those not aware, 6u10 is the release with
- Direct3D acceleration for Java 2D on default
- New Nimbus LF for Swing
- New Quick-starter for windows
- New Java Kernel installer for windows for smaller, faster download and 
first time startup

- New Java plugin for better stability, plus many new cool features.
- Updated hotspot VM
- plus, plus, plus ..

We hope to GA/FCS this summer, so the more and earlier feedback the better.
Spread the word.

TIA,

-Phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Poor quality rotated text

[Phil Race]

I think this is a consequence of trying to position each glyph at the 
closest point its projection
on to the theoretical baseline on a relatively low-res device. I suspect 
it would look fine at
printer resolutions. Whilst rotating an image would help the baseline I 
don't think you'd be

happy with the appearance of the glyphs.

Your best option for quality is likely to get the outline of the text 
and use
Graphics2d.fill(Shape). You'll also want to set ANTIALIAS_ON (that's the 
graphics
AA flag not the text one since here you are rendering a shape, not a 
text primitive).


The most robust way to get the outline of the text is by calling 
TextLayout.getOutline(..);


-phil.

[EMAIL PROTECTED] wrote:

When rotated at some angles the position of characters relative to the baseline 
is a bit erratic (by a pixel or so). This still occurs with text antialiassing 
and/or fractional metric hints enabled. I'm using jre6_u04.
I was wondering if it would be better to render the text (horizontally) into a 
bitmap (possibly at higher resolution) and then rotate and draw the resulting 
bitmap.
Performance is not a great concern as the result is cached.

Any suggestions?
[Message sent by forum member 'mthornton' (mthornton)]

http://forums.java.net/jive/thread.jspa?messageID=262205

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
  


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How do I turn on kerning?

[Phil Race]

Its been a couple of weeks but yesterday finally looked into this.
The problem is indeed specific to the version of the font on Vista
and so affects 32 and 64 bit.

When Microsoft added support for Arabic (etc) to the Times New Roman
font (and others) they added an OpenType 'GPOS' table which is
*supposed* to be the way to do kerning in an OpenType font.
However they did not in fact add kerning information to the table.

On a separate list I received email from Adobe that they also
found the same problem with the Vista fonts.

So really this appears to be a bug in the Vista fonts which
we'll have to see if we can workaround, but really the JDK
is doing just what the font tells it to do.

Anyway I filed bug 6663396 to track it and decide what to do.
It should show up in a day or so on bugs.sun.com

-phil.

[EMAIL PROTECTED] wrote:

Hi Phil,

The Vista machine is 64-bit and the XP machine is 32-bit so perhaps that has 
something to do with it.

Anyway, I have emailed you screen shots of the problem so you can see it.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How do I turn on kerning?

[Phil Race]

But you aren't using the same font as the previous reporter.
Serif on Linux uses Lucida Bright, which has no 'kern' table,
so that is expected.

-phil.


[EMAIL PROTECTED] wrote:

qu0ll

I see the same problem on Linux (Ubuntu Gutsy 32-bit) -

Java(TM) SE Runtime Environment (build 1.6.0_03-b05)

The kerning applet example on the Java 2D tutorial shows no difference between 
kerning and no kerning.
[Message sent by forum member 'frank_costanza' (frank_costanza)]

http://forums.java.net/jive/thread.jspa?messageID=256393

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How do I turn on kerning?

[Phil Race]

I didn't get much time today. So I didn't try Vista myself, except that 
I dumped
Times New Roman and the Vista and XP versions of the 'kern' table appear 
identical,

even though the font itself is about double the size on Vista vs XP.

So perhaps  ..
no kerning on Vista x64

there's a bug in the native code that affects 64 bit ?? Was your XP case 
32 or 64 bit?


-phil.

Phil Race wrote:

Dmitri's pointers are valid.

Vista shouldn't make a difference to 2D since the code isn't OS 
specific and isn't making any OS provided
calls. Perhaps the fonts just aren't the same. I do believe that Times 
New Roman etc were expanded for Vista.
Still, that is surprising. Don't have Vista handy right now to look 
how the tables are different. Its possible
that it now uses more than one subtable, and when we did this work I 
don't think we found kern tables
like that to test against. But that was pre-vista. I'd need to see a 
test case.


-phil.

[EMAIL PROTECTED] wrote:

That didn't help but I have noticed that the examples on this page:

 

ttp://java.sun.com/docs/books/tutorial/2d/text/textattributes.html



show no effect with kerning on or off on my Vista machine but do show 
a difference on XP.


Could this be a bug under Vista?

  




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How do I turn on kerning?

[Phil Race]

Dmitri's pointers are valid.

Vista shouldn't make a difference to 2D since the code isn't OS specific 
and isn't making any OS provided
calls. Perhaps the fonts just aren't the same. I do believe that Times 
New Roman etc were expanded for Vista.
Still, that is surprising. Don't have Vista handy right now to look how 
the tables are different. Its possible
that it now uses more than one subtable, and when we did this work I 
don't think we found kern tables
like that to test against. But that was pre-vista. I'd need to see a 
test case.


-phil.

[EMAIL PROTECTED] wrote:

That didn't help but I have noticed that the examples on this page:

  

ttp://java.sun.com/docs/books/tutorial/2d/text/textattributes.html



show no effect with kerning on or off on my Vista machine but do show a 
difference on XP.

Could this be a bug under Vista?

  


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Load and display OpenType Fonts

[Phil Race]

Depends what you mean by OpenType. If you mean specifically the CFF
(Postscript outlines) subset of OpenType then JDK doesn't support that.
There's an open RFE on this : http://bugs.sun.com/view_bug.do?bug_id=4356282

-phil.

[EMAIL PROTECTED] wrote:
Hello, 

I noticed that [i]sun.font.FontManager.getFontsFromPlatform()[/i] does not return OpenType Fonts installed on a System (using Windows XP, SP2, Java 1.6.0_05-ea). Aswell creating new Font objects with OpenType Fonts as name does not work too. 


Is there any way to load and render Fonts with Graphics2D, or is there any 
JSR/other library capable of that (as far as my googling skills tell: there 
isn't)?

regards, 
newcron

[Message sent by forum member 'newcron' (newcron)]

http://forums.java.net/jive/thread.jspa?messageID=253698

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Font kerning/spacing issues ?

[Phil Race]

Michele Puccini wrote:

Phil, David,
 
many thanks for your help.
 
Phil, you say thay the KERNING hint is not there by default because:
 
1) changes the overall text length

I mean that you obviously can't expect text to be the
same length with this option on, and so you need to
make sure any code that is fussy about the length
measures the font in the presence of the attribute.


2) requires extra processing steps at rendering time.


Yes, I mean that text that is rendered with kerning will be much
slower to render. This is unlikely to be an issue in practice
unless you are doing massive and continual updates, but its
a fact that if you ask for more work to be done, it takes longer.


-phil.

 
Do you mean that I may also encounter performance or compatibility issues ?
 
Mik


  ClassX Development Italy  Via Francesca, 368/I I-56030 S.M. a Monte 
(PI) 
  Tel.(+39)-0587-705153  Fax.(+39)-0587-705153  WEB: 
http://www.classx.it  


=== 
To unsubscribe, send email to [EMAIL PROTECTED] and include in the 
body of the message signoff JAVA2D-INTEREST. For general help, send 
email to [EMAIL PROTECTED] and include in the body of the message 
help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Font kerning/spacing issues ?

[Phil Race]

 Where's the problem with java2d font rendering ?

Nothing's wrong.

CorelDraw is a word-processor and is applying kerning.

Not sure what you mean by any other gfx program.

If you use windows notepad I see the same there in Font2DTest,
which is what I would expect since windows GDI provides
no way to request kerning.

The way to get kerning in jdk6 is to say you want it by
adding the appropriate attribute to the font :
http://java.sun.com/javase/6/docs/api/java/awt/font/TextAttribute.html#KERNING

Its not applied by default since it
1) changes the overall text length
2) requires extra processing steps at rendering time.

-phil.

Michele Puccini wrote:

Hello all at Java2D,
 
please take a look at this picture:
 
www.classx.it/public/font2dtest.jpg 
http://www.classx.it/public/font2dtest.jpg
 
the first LATIN text is rendered with Java2d (1.5, 1.6, winxp)
the second is rendered with CorelDraw (but I get the same result with 
any other gfx program).
 
You can notice an abnormal spacing between the A and the T glyphs in 
the java version.

The CorelDraw version looks more correct, IMHO.
 
I've tested many other fonts but I always got the same results.
 
Where's the problem with java2d font rendering ?
 
Cheers,
 
Mik


  ClassX Development Italy  Via Francesca, 368/I I-56030 S.M. a Monte 
(PI) 
  Tel.(+39)-0587-705153  Fax.(+39)-0587-705153  WEB: 
http://www.classx.it  


=== 
To unsubscribe, send email to [EMAIL PROTECTED] and include in the 
body of the message signoff JAVA2D-INTEREST. For general help, send 
email to [EMAIL PROTECTED] and include in the body of the message 
help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Direct3D is disabled in win2003 in 6uN EA?

[Phil Race]

Ken,

Please read the subject line.
Windows 2003 and 2008 are server OSes and are quite different
than windows 2000.

-phil.

Ken Warner wrote:

The funny thing is that Windows 2000 wasn't a server class OS
when I bought it.  It was just the latest Windows.  Somewhere
along the line it became a server OS.  And I didn't know
I became an Administrator.  I guess I didn't get the memo.

And the reason I don't upgrade to XP or (yuk) Vista is that I'd rather
spend my cycles on work rather than fancy icons and animation
to give me a ...richer user interface experience...  Windows 2000
is almost as fast as Windows NT

I guess it's just a matter of perspective.

And there's no point in telling Microsoft anything -- they
know *ALL* the answers.  It's not my fault!

Dmitri Trembovetski wrote:


Ken Warner wrote:


The assumption that,


...typically people don't care about
  graphics performance on a server, and also drivers
  tend to be old/buggy on servers as they are not
  updated as often.



Is fundamentally wrong -- at least in my case. 



  You may want to tell that to Microsoft then, because in their
  next server os (Windows 2008) not only Aero is disabled
  by default, it is not even present in the installation,
  and the default (and only) theme is Win2k. I guess they have
  found that administrators don't care much about fancy
  graphics on servers.

  Moreover, the vast majority of servers are
  administered remotely anyway.

  Thanks,
Dmitri




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How to set custom paper size using printer jobs

[Phil Race]

[EMAIL PROTECTED] wrote:

Hi Phil,

The problem I have posted regarding the custom paper size is very important for 
one of our customers who has more than 60 clients with the same printer and the 
same paper format. I need to know if there is another way around to solve this 
problem.



Sorry I've been out and busy. I'll look into more this when I get time.
If you need something more definite, then that's where a support
contract comes in :)

But I did get so far as to install the driver for the Epson printer and
I see no indication that
it supports custom paper sizes. Every windows driver I've seen that does
has to provide
a way for the user to specify that size. You claimed this works in
wordpad, but
again, I don't see that functionality there. How exactly did you do this ?


If this is a bug of the jdk, when it is going to be solved?



Depends. Probably JDK 7 ...

-phil.

Best regards,

Lucho.
[Message sent by forum member 'lucho01' (lucho01)]

http://forums.java.net/jive/thread.jspa?messageID=241956

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How to set custom paper size using printer jobs

[Phil Race]

Right, on windows, the default paper size is based on the default
for the printer which is what makes a lot more sense than a hard-coded
value. I believe this was fixed a LONG time ago (1.3 ie 1999-2000)

-phil.

[EMAIL PROTECTED] wrote:

I forgot to mention that, at that time, the default paper size was Letter, 
which was fine for people living in the US, but rather annoying for people 
living in Europe.

That is why I had to create my own A4 class.

Have a nice weekend.
[Message sent by forum member 'pietblok' (pietblok)]

http://forums.java.net/jive/thread.jspa?messageID=241290

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How to set custom paper size using printer jobs

[Phil Race]

If your printer doesn't support custom paper sizes, then
setting one will just cause the closest supported paper
size to be used.

However there is also a bug specific to the case when the
end user then changes the printer in the print dialog
to one that is not the system default one where we
validate against the original printer, not the selected one.

That's 6359283 PrinterJob.pageDialog() ret. incorrect PageFormat when 
non-default
printer used. Its only fixed in JDK 7 builds.
http://bugs.sun.com/view_bug.do?bug_id=6359283

If neither of the above describe your situation, then
try running the latest JRE : 1.6.0_03 (you didn't mention
this so far as I could see).

If none of that helps you would need to provide a complete small
self-contained test program (not just code snippets), and also
the exact JRE version (output from java -version) and
also the O/S and printer model and driver so we could
look further.

-phil.

[EMAIL PROTECTED] wrote:

Hi Piet thanks for your help, I am trying to resolve my problem using your code 
but it did not worked. I am still getting the size A5 no matter what I try to 
define. I don't know if I am missing something. Please look at the following 
code and see if you can find what I cant find.

PageFormat pageFormat = createFormat();
try {
job.setPrintable(this,pageFormat);
if (job.printDialog()) {
job.print();
}
} catch (PrinterException e) {
e.printStackTrace();
}


private PageFormat createFormat() {
PageFormat format = new PageFormat();
format.setPaper(new Custom());
return format;
}

private class Custom extends Paper {

public Custom() {
super();
setSize(491, 594);
setImageableArea(36.0, 36.0, 522.99212598425197, 
450.8897637795276);
}
}
[Message sent by forum member 'lucho01' (lucho01)]

http://forums.java.net/jive/thread.jspa?messageID=241236

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How do I install the 1.6 beta as my browser plugin?

[Phil Race]

 I downloaded jre-6u5-ea-bin-b04-windows-i586-27_sep_2007.jar

SFAIK this is just a self-extracting jar file that dumps
the files on disk - its not an installer.
You must use one of the installer downloads - eg the .exe download

-phil.

Ken Warner wrote:

Hi,

I downloaded jre-6u5-ea-bin-b04-windows-i586-27_sep_2007.jar to try D3D
acceleration.  When I install it, there is no installation as browser
plugin.

I imagine this is intentional.  Is there a way to force it to be a
browser plugin?

I would like to see real world performance in the browser.

I tried jre-6u5-ea-windows-i586-p-iftw.exe and that gives me about a
three time performance boost in general computation and about a 1/3'd
performance boos in drawing.

I'd like to compare the beta in the same environment.

Ken

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Ok -- what's the deal on the spyware in Java 1.6?

[Phil Race]

[EMAIL PROTECTED] wrote:

First, nothing to do with Java2D.


yep.



Second, jusched.exe is Java Update Scheduler. It is a process that checks for 
automatic updates to the installed JDK / JRE. You can configure it (including 
disable) in the control panel of the Java tray icon.
[Message sent by forum member 'kirillcool' (kirillcool)]



I heard that it may also be removed maybe in 6uN, in favour of a
system that does the check sometime when you are running plug-in
or webstart. It was also suggested that such tools be named more
clearly like JavaUpdateScheduler.exe so people have a better
clue what they do.

-phil.



http://forums.java.net/jive/thread.jspa?messageID=239414

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Java2D/Swing problems w/small, bold ClearType fonts?

[Phil Race]

-phil.
[EMAIL PROTECTED] wrote:


- With Windows Display - Appearance - Effects font smoothing set to 
ClearType, Monospaced bold 13 looks chunky in Swing (irrespective of Swing 
anti-aliasing settings) and normal in AWT.

(By normal, I mean roughly identical to Windows Notepad. I cannot compare 
Monospaced in Windows Notepad, since it doesn't exist, but I can compare it to Courier New, which 
is either really close or the same font under the covers.)




JDK does use the system's Courier New as the primary font for monospaced
(the suggestion from another poster you are getting a Lucida font is
incorrect).

What this appears to come down to is something MS are doing to make
Courier New Bold look less bold, specifically in ClearType mode.

If I look at it in either BW or greyscale antialiasing (aka windows
standard
font smoothing) then you'll see that notepad is bold. To see what I mean,
if you set Courier New Bold at pt size 16 (using 96 dpi) in windows
notepad,
with set your windows font smoothing initially set to Standard, its
identical
to the JDK rendering of the same size (16 pt with AA or GASP in
Font2DTest).
But if you then change it to Cleartype in notepad the text gets
noticeably lighter.
But I see this only for Courier New Bold. Not all bold fonts.
Eg If I use Microsoft Sans Serif instead I don't see the same difference.
And Tahoma Bold also looks very bold in ClearType mode.

So it looks possible that MS special case Courier New Bold in cleartype
mode,
to make it look thinner , not even really bold. We'd have to look into
whether
we should do that too, but my initial opinion is that  the ClearType
rendering is
not true to the font.



Interestingly (to me, at least), but probably unrelated - I tried this with the Font2DTest demo, 
and discovered that antialiasing=default was the same as antialiasing=off, 
even though I'm running on Windows XP SP2 on an LCD display with ClearType turned on.  And that 
remained true even when I explicitly specified -Dawt.useSystemAAFontSettings=lcd on the command 
line.  You can see my Font2DTest chunky boldness here:
.


Font2DTest's 'default' means Java 2D's default behaviour, not the
desktop default ... and the value
of default historically and presently in Sun's JDK happens to be OFF.
We've talked about changing that so DEFAULT matches the desktop but have
been a bit
leery of the compatibility consequences.

-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Java2D/Swing problems w/small, bold ClearType fonts?

[Phil Race]

So why does AWT get the ClearType rendering?  Does it drop down to native font 
rendering?


The AWT components are the windows native components, and so
windows (GDI) does all their rendering, not just the text.

-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Java2D/Swing problems w/small, bold ClearType fonts?

[Phil Race]

Phil Race wrote:


font smoothing) then you'll see that notepad is bold. To see what I mean,
if you set Courier New Bold at pt size 16 (using 96 dpi) in windows
notepad,


Sorry, that should be 12 pt in windows, which == 16 pt in JDK

-phil

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Java2D/Swing problems w/small, bold ClearType fonts?

[Phil Race]

The Lucida case looks marginally bolder in notepad .. so this isn't
exactly what
you were describing. I don't see much difference in the consolas one.

But 13 is a bad size to be sure to compare properly because it doesn't
exactly equate
12 pt in JDK/Font2DTest and 9 pt at 96 dpi  in notepad would be better

-phil.

[EMAIL PROTECTED] wrote:

Phil wrote:



What this appears to come down to is something MS are doing to make
Courier New Bold look less bold, specifically in ClearType mode.



OK, I tried a few other monospaced fonts, and my two faves also have the same 
problem:

http://www.jay.fm/files/consolas.png
http://www.jay.fm/files/lucida-sans-typewriter.png

Thoughts?
[Message sent by forum member 'jay_levitt' (jay_levitt)]

http://forums.java.net/jive/thread.jspa?messageID=234960

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How to keep the rasterizer at bay when printing?

[Phil Race]

Olivier Lefevre wrote:

No, you wouldn't. It makes no difference. No one is asking *you* to
create a raster.



Misunderstanding.

Yes. You are misunderstanding. The printer raster path is at the same
resolution as the pdl path
Both will be different than the screen resolution which you are
hardcoding to.

-phil.


 Let us say I have a line plot with a thousand points,
many tick etc. I have a to convert their coordinates from whatever data
space they come from to actual pixel positions on the device (the
screen). Now because it's a lot of computation I save these positions.
If suddenly I am requested to paint the plot onto a device with a different
size/resolution I cannot simply use the state backing what is on the
screen, for obvious reasons. One possibility is to simply apply a scaling
factor in the Graphics2D object to the saved positions but that is exactly
the strategy that fails with raster images. Thus either I must create a
second, invisible copy of the widget with the appropriate backing state
and paint _that_ to the printer or else I must keep around a second version
of paintComponent that does not use the saved pre-computed positions but
computes them on the fly. Is it clear now?

The bottom line is that being unable to simply scale the drawing and
having to paint it at its real size/resolution does put a burden
on the developer.

-- O.L.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How to keep the rasterizer at bay when printing?

[Phil Race]

Olivier Lefevre wrote:

And it makes no sense for Java 2D printing to implement only a subset of our
own API.


When rendering onto a target (i.e., a printer driver) that makes it
inordinately
difficult to support certain features and forces drastic trade-offs, I think it
could make sense.


I don't see that as  desirable or truly useful and its obviously completely
non-standard.


But blurry rasters are not useful either and it _is_ standard behaviour for
software acting on markup or page descriptors to skip unprocessable
instructions.


The blurry raster is solely because you tried to send a screen resolution
swing ui to the printer. ie print a lo-res image scaled up massively.
The printing rasterisation is high quality.

-phil

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How to keep the rasterizer at bay when printing?

[Phil Race]

No, you wouldn't. It makes no difference. No one is asking *you* to
create a raster.
The implementation creates the raster in a way that is completely
transparent to your code.
Its an implementation detail of the graphics instance and its
relationship to the surface
to which you are drawing.

-phil
.
Olivier Lefevre wrote:

The blurry raster is solely because you tried to send a screen resolution
swing ui to the printer. ie print a lo-res image scaled up massively.
The printing rasterisation is high quality.



Yes I know but in order to send data to the printer at the printer res I
would need to implement a complement different painting path: the image
is complex enough that I cache a lot of information instead of computing
it on the fly within paintComponent. Now with a pdl path (e.g., when
saving to PDF or using the forbidden pdl pipeline) I can simply apply
a scaling factor and get mostly correct results (slight mismatches with
fonts at most) whereas with a raster path I'd need to keep 2 copies of
the plot around: one for for the screen and one for the printer, or else
implement 2 modes: one with caching, another without. So it's a bother.

-- O.L.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How to keep the rasterizer at bay when printing?

[Phil Race]

Olivier Lefevre wrote:

Since (surprise) 'pdl'  didn't help try 'raster', which is the opposite
of what you  think is helpful but might be interesting.


Thanks for the answer but I think the sarcasm is misplaced. Pease google
sun.java2d.print.pipeline and see for yourself how much information
you get. I could not find a list the possible values nor an explanation
of what they do, only a hint that pdl might be a good idea.


Well since this is internal implementation of the Sun JDK, and not in fact
a standard property its not surprising its not documented.
Its principle use is internal testing.

Generating PDL graphics instructions ie NOT a rasterised bitmap
is what the JDK does by default and strives to do whenever it can.

So specifying PDL is either a no-op, or is possibly going to
cause a failure at runtime since you are forcing an inappropriate path.





Furthermore it seems this decision reflects late 1990s thinking re. the
capabilities and speed of some printers. Isn't it time to revisit?

No, its the late eighties Microsoft APIs that limit what we can do.


How do the MS APIs come into the picture? Unless we are talking about
so-called Windows printers that render on the desktop and thus using GDI,
I would not think they are involved. To be sure they are an important
use case but they are not even the majority of printers.


I don't know what you are driving at.
The standard way to print graphics on windows is via GDI,
unless perhaps you are a .NET app, but even then I'll bet its
translated into GDI under the covers as that's what the windows
printer driver API wants.

And GDI doesn't have an API to create a translucent color

Color c = new Color(255,255,255,128);

simply isn't available.

So things like that force a bitmap but I am doubtful its relevant
to your case :



In any case the point is not just printers: you can print or paint
to Graphics2D instances that generate PostScript, PDF, SVG or whatever
and it is extremely unhelpful when they are sent a bitmap instead of
the expected graphics instructions that you put in your code. There
ought to be a switch to turn off rasterization *unconditionally* and
ensure graphics command are sent exactly as they are written. As it
is, the only way I could find to do that is to bypass the high-level
print/paint methods and call paintCompoment and paintBorder directly.
That works but then I have to perform nested widget placment, background
printing etc manually, which is quite a bother. Is there a better way
that I have overlooked?


Ah! I suspect this is your application bug.

Are you seeing this only when printing a Swing UI?
How are you printing?

Are you calling component.paint(printerGraphics) on the printer graphics.

Remember that Swing is double-buffered by default so
it does all its painting to an off screen image and that
printerGraphics for the printer sees only the resulting image.
So its nothing to do with the printing implementation.

You need to call Component.print() or Component.printAll() in which
case Swing renders directly to the printer graphics.

-phil.





Regards,

-- O.L.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How to keep the rasterizer at bay when printing?

[Phil Race]

Olivier Lefevre wrote:

I could not find a list the possible values nor an explanation
of what they do, only a hint that pdl might be a good idea.



It now occurs to me that PDL must stand for Page Description Language,
i.e., just what I wanted but you say it's normally a no-op.



I don't know what you are driving at [with you remarks on Windows printers]



I am vague on the architecture of Windows printing. I was hoping that in the
case of real printers (i.e., with their own rasterizers) applications are
talking directly to the printer driver that is installed with the printer,
not to some generic Windows printer driver. If that's not the case maybe
for high-quaklity printing you are better off generating PostScript and
sending that directly to the printer? A few printers also understand PDF.



Postscript also doesn't support translucency except in some unlikely and
esoteric implementations
and whilst windows provides a way to see if a printer is a postscript
one it provides no such API for determining
if its a PDF printer.






Are you seeing this only when printing a Swing UI? How are you printing?



Yes, I was printing a JPanel with plots in it, i.e., just text ad line art
but with some transparency.



Are you calling component.paint(printerGraphics) on the printer graphics.



No I was calling print and I even turned off Swing buffering manually but
I was still getting bitmaps. However now that you told me that print never
rasterizes I went back and I realized the problem is that a sub-widget was
doing its own buffering for performance reasons and I was not turning off
_that_. It seems to work fine now. Thanks!

While we are talkinmg, I have a subsidiary question. When printing or saving
to file the print size is not necessarily what is shown on the screen. One
can simply apply a scaling transform to the graphics object or one can keep
around a private, non-displayable copy of the widget and resize that one
before printing it. The first solution is simpler but are there any gotchas
with rescaling that I am not aware of?




I can't say what you are not aware of until you tell me everything you
are aware of.

Image rescaling will work but be blurry like you complained about to
begin with.
One common mistake is to assume that text scales linearly from screen to
printer.
It doesn't.

If  you scale the graphics 4x then a specific piece of text might scale
by 3.87 or 4.23, or 3.95 , or ..

you can only measure text in the right context. So code that supports
printing of a layed
out component needs to use the screen FontRenderContext for the text.

-phil.

Regards,

-- O.L.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] disable bidi reordering in TextLayout

[Phil Race]

There won't be a Graphics hint to affect bidi behaviour since
that is completely un-related to the graphics.
A text layout only needs a graphics instance so it knows
where to send the already laid out text.

Perhaps what you want it to explicitly specify
java.awt.font.TextAttribute.RUN_DIRECTION_LTR as the value
for the attribute java.awt.font.TextAttribute.RUN_DIRECTION
to your text layout constructor.
This will over-ride the standard bidi behaviour.
(see java.text.Bidi)

-phil.

Brien Colwell wrote:

hi All,

I'm experiencing something interesting with TextLayout. If I render a
string
that has runsLRL,   where L is left-to-right and R is
right-to-left,   everything looks good. However, if I render a string
that has runsRL,  the R run is rendered at the end of the line.

I have a pretty tricked out Swing text view that breaks up lines in
strange ways. I'd like to disable reordering altogether. Is there a
graphics hint to do this? I'm also wondering if I'm totally off in
thinking the TextLine is doing any reordering ... ?

Displaying right-to-left text is not important to me. Since I'm not
playing right with Swing's bidi root stuff, I need to be able to hack
the text layout into shape.


Thanks!
brien


Pinpoint customers
http://us.rd.yahoo.com/evt=48250/*http://searchmarketing.yahoo.com/arp/sponsoredsearch_v9.php?o=US2226cmp=Yahooctv=AprNIs=Ys2=EMb=50who
are looking for what you sell.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body of the message signoff JAVA2D-INTEREST. For general help, send
email to [EMAIL PROTECTED] and include in the body of the message
help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Printing data in dotmatrix printer with formating

[Phil Race]

This is all between you, jasper reports, and your printer.

AUTOSENSE basically just pumps the data in the file to the printer port
(via GDI APIs).
Not really different than :

copy bill.html LPT1:

So you can only send via AUTOSENSE something your printer understands.
For dot matrix printers basic ASCII text with newlines, tabs etc is
probably  OK
But its a bit suspicious that your file name ends with .html
I doubt there's a dot matrix printer in the world that can render HTML
directly

-phil.


[EMAIL PROTECTED] wrote:

I have a dot matrix printer nad i want to print data directly to the dot matrix 
printer. I have use the JasperReport as reporting tool but it prints very 
slowly. I have also use the JRTextExporter exporter = new JRTextExporter(); for 
exporting reports in text but it can't make a good alignment to the text and 
event i can't do any type of formatting in the text File. My Code is

[b]public void convertToText[/b]() {
JRTextExporter exporter = new JRTextExporter();

File file = new File(C:\\bill.html);
try {


exporter.setParameter(JRTextExporterParameter.JASPER_PRINT,report.getReport());
exporter.setParameter(JRTextExporterParameter.OUTPUT_FILE, file);
exporter.setParameter(JRTextExporterParameter.PAGE_HEIGHT,new 
Integer(15));
exporter.setParameter(JRTextExporterParameter.PAGE_WIDTH,new 
Integer(22));
exporter.setParameter(JRTextExporterParameter.CHARACTER_WIDTH,new 
Integer(30));
exporter.setParameter(JRTextExporterParameter.CHARACTER_HEIGHT,new 
Integer(30));
exporter.exportReport();

getPrinter(file);

} catch (Exception ex) {
ex.printStackTrace();
}
}

[b]public void getPrinter[/b](File file)
   throws PrintException, FileNotFoundException {

javax.print.DocFlavor flavor = 
javax.print.DocFlavor.INPUT_STREAM.AUTOSENSE;

javax.print.attribute.PrintRequestAttributeSet pras =
new javax.print.attribute.HashPrintRequestAttributeSet();



PrintService printService  = 
PrintServiceLookup.lookupDefaultPrintService();
javax.print.DocPrintJob job = printService.createPrintJob();

java.io.FileInputStream fis = new java.io.FileInputStream(file);
javax.print.attribute.DocAttributeSet das = new 
javax.print.attribute.HashDocAttributeSet();
javax.print.Doc doc = new javax.print.SimpleDoc(fis, flavor, das);
job.print(doc, pras);

}
}
[Message sent by forum member 'aroop_bh' (aroop_bh)]

http://forums.java.net/jive/thread.jspa?messageID=227537

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Bug in rendering text under JDK 6.0

[Phil Race]

It is completely cross-platform.
Looks like a case where I forgot to ask that the text pipes be re-validated.
I think it may be as little as a one line fix for setComposite to set a
flag that some font rendering settings need to be re-validated.
I see Igor filed bug 6576507 for your test.

Its probable that there's a workaround of setting some other hint
at the same time that will tickle the re-validation.

-phil

[EMAIL PROTECTED] wrote:

Okay, now that's just weird. :|  Garbling happens under WinXP as well.

It seems to be related to LCD text settings.  For as far as my limited testing 
took me, enabling ClearType will garble the second line.  As soon as it is 
enabled/disabled (no need to reload/recompile), the second line changes.

Did some further testing: could it be that the wrong pixels are taking for 
AlphaComposite?  I have the impression that the pixels drawn onto the screen are really 
just test but with each pixel repeated three times:

[code]
+++
+  x  +
+x+
+  x  +
+  x  +
+  x  +
+   xx+
+++

 ==

+++
+ +
+ xxx +
+ +
+x+
+x+
+x+
+ +
+++
[/code]

Changing the LCD orientation (horizontal to vertical) also changes the pixel's positions, but they 
seem to have correct horizontal spacing, hence.  In the horizontal case, if we could 
just take each third pixel, we'd get test back, I believe.
[Message sent by forum member 'tarbo' (tarbo)]

http://forums.java.net/jive/thread.jspa?messageID=225069

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Bug in rendering text under JDK 6.0

[Phil Race]

 I'd be very interested in a workaround.

There's probably several things that will work, but
something as simple as this does the trick for me, and
will be fairly cheap.

// if this line is removed, everything is OK
graphics.setComposite(AlphaComposite.getInstance(
AlphaComposite.SRC_OVER, 0.6f));
Font font = graphics.getFont();
font = font.deriveFont(font.getStyle(), font.getSize2D());
graphics.setFont(font);
graphics.drawString(test, 10, 80);

it works because even though the font is the same as before,
the implementation treats it as simpler to simply set the new
font (since its not == the old one), and re-validate.
Since you need to revalidate anyway here, nothing is lost there.

-phil

[EMAIL PROTECTED] wrote:

Its probable that there's a workaround of setting
some other hint
at the same time that will tickle the re-validation.


I'd be very interested in a workaround. I was thinking about rendering the 
second text into a temporary image. Should work (if that would be the first 
text rendered there), but i'm worried about the performance hit - creating an 
image every time i need to paint the text of a button / toggle button / radio 
button / checkbox / ...

Thanks
Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]

http://forums.java.net/jive/thread.jspa?messageID=225089

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Value to use for RenderingHints.KEY_TEXT_ANTIALIASING in a library

[Phil Race]

AA text used to be very slow once upon a time but I think I sped it up
mostly in 1.5 not 6
There could be other reasons why its 'faster' now. ie  better detection
that rendering
involves readback from the surface (not specifically  for text) which
can be slow
on AGP buses ..
As for the best default to use, there is a public mechanism built into
JDK6 to
let you get the hints that correspond to the system default. Swing
already uses this

See
http://java.sun.com/javase/6/docs/api/java/awt/Toolkit.html#getDesktopProperty(java.lang.String)

which directs you to the following detailed  explanation
http://java.sun.com/javase/6/docs/api/java/awt/doc-files/DesktopProperties.html

-Phil

[EMAIL PROTECTED] wrote:

Hi

I'm looking at how we support AA for text in the Flying Saucer library. Before 
Java 6 (we support back to 1.4 for the library), we found AA to be pretty slow, 
hence we had it turned off by default. I just turned it back on and found 
performance, at least with JDK 6, to be great--now my question is which of the 
many possible values for RenderingHints.KEY_TEXT_ANTIALIASING we should use by 
default when our users ask for AA text to be enabled. We set the value before 
performing text operations (drawString()). I'll probably give them the option 
via our configuration file, but am wondering what we should use as a default 
recommended value--in our case, we don't know what systems the library will be 
used on. Any reasonable approaches you can recommend?


Thanks
Patrick
[Message sent by forum member 'pdoubleya' (pdoubleya)]

http://forums.java.net/jive/thread.jspa?messageID=212445

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Retiring the package com.sun.image.codec.jpeg

[Phil Race]

I received the test image from Carl and it does have an APP2 marker
with an ICC profile so its as I suspected.
com.sun.image.codec.jpeg is faster mainly because its not processing
this.

On my XP PC for 50 loads of the sample image I have
ImageIO : 32 seconds
JPEGDecoder : 13 seconds

But if I allow Image I/O to skip applying the color space conversion
I get 15 seconds - almost on a par ..

The way to 'skip' this is to specify that the returned buffered
image use the color space with the profile, rather than being
converted to sRGB before returning.

This does mean you need to directly invoke the JPEG reader
so you can tell it this. Sample code below :

There's a couple of robustness things lacking (like not
checking for null) but that's pretty much what you need.


IteratorImageReader it = ImageIO.getImageReadersBySuffix(jpg);
ImageReader jpegReader = it.next();
jpegReader.setInput(new FileImageInputStream(file));
IteratorImageTypeSpecifier typeIterator = jpegReader.getImageTypes(0);
ImageTypeSpecifier its = null;
while (typeIterator.hasNext()  its == null) {
ImageTypeSpecifier tmp = typeIterator.next();
ColorSpace cs = tmp.getColorModel().getColorSpace();
if ((cs.getType() == ColorSpace.TYPE_RGB)  !cs.isCS_sRGB()) {
its = tmp;
  }
}
ImageReadParam param = jpegReader.getDefaultReadParam();
param.setDestinationType(its);
BufferedImage bimg = jpegReader.read(0, param);

It used to be the case that this was the default.

However notice that drawing this image will now take
longer as the conversion will be applied then.
This turned out to be a problem too for most people.
So this is probably not going to help if you need to
do that drawing anyway. We've discussed whether applying the
conversion is really necessary if RenderingHint.KEY_RENDERING
is set to VALUE_RENDER_SPEED, and the image types are generally
compatible, so perhaps in the future that will offer a solution.

In the interim you could just create a new BufferedImage
using the Raster from the returned one and a color model
which has an sSRGB color space .. ie essentially dropping
the ColorSpace which has the ICC profile data.

-phil.

Phil Race wrote:

There may be some differences in the way that the two APIs process the
image.
For example I noted recently that the old com.sun.image.codec,jpeg is
completely
ignorant of an APP2 marker with an ICC profile in which case its faster,
but produces incorrect
results.  So for many photographic images it probably should not be used
on those grounds
alone. I am not at all sure that's the issue in your case. It would
need  investigation .
Can you send me (not the whole list) directly via email your  test image.
phil DOT race AT sun DOT com

-phil.

[EMAIL PROTECTED] wrote:

I've run some tests and concluded that JPEGCodec.createJPEGDecoder(new
FileInputStream(file)).decodeAsBufferedImage() is faster than
ImageIO.read(new File(file)) .
I have a test image that's 1978x2500 that loads in 375ms using
JPEGCodec and 735 ms using ImageIO. I set ImageIO.setUseCache(false).
Is there something I'm doing wrong or is the old package faster. I'm
writing an application to read images/slideshow, etc and speed is very
important. Do you have any tips or suggestions?
I'm running Java 6 u1 on Windows XP Media Center. 128MB VRAM, AMD
Athlon 3800 Dual Core X2, 1GB RAM.

Thanks in advance,

Carl Antaki
[Message sent by forum member 'carcour' (carcour)]

http://forums.java.net/jive/thread.jspa?messageID=211620

===

To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Retiring the package com.sun.image.codec.jpeg

[Phil Race]

I tried it.

what is the percentage differential you measure?
I trust you ran a benchmark which ran a loop of (say) 50 times?

I have read somewhere that the C library used is not efficient and
that the Intel library is faster.

no idea what that's about. Both APIs use the same C lib. Its the IJG lib
which  is very widely used
and hopefully easily optimised by C compilers.
Did you try the jai tools version of image i/o? That has some different
code .. supposedly faster.

-phil.

[EMAIL PROTECTED] wrote:

Thanks Phil.
I tried it. It it is a faster but not as fast as the old library. It still 
looks to me that at 400ms this is slow. Shouldn't it be possible to make a 
multi threaded image reader. Do you know what is really taking most of this 
time? I have read somewhere that the C library used is not efficient and that 
the Intel library is faster.

Carl
[Message sent by forum member 'carcour' (carcour)]

http://forums.java.net/jive/thread.jspa?messageID=212003

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Retiring the package com.sun.image.codec.jpeg

[Phil Race]

There may be some differences in the way that the two APIs process the
image.
For example I noted recently that the old com.sun.image.codec,jpeg is
completely
ignorant of an APP2 marker with an ICC profile in which case its faster,
but produces incorrect
results.  So for many photographic images it probably should not be used
on those grounds
alone. I am not at all sure that's the issue in your case. It would
need  investigation .
Can you send me (not the whole list) directly via email your  test image.
phil DOT race AT sun DOT com

-phil.

[EMAIL PROTECTED] wrote:

I've run some tests and concluded that JPEGCodec.createJPEGDecoder(new 
FileInputStream(file)).decodeAsBufferedImage() is faster than  ImageIO.read(new 
File(file)) .
I have a test image that's 1978x2500 that loads in 375ms using JPEGCodec and 
735 ms using ImageIO. I set ImageIO.setUseCache(false). Is there something I'm 
doing wrong or is the old package faster. I'm writing an application to read 
images/slideshow, etc and speed is very important. Do you have any tips or 
suggestions?
I'm running Java 6 u1 on Windows XP Media Center. 128MB VRAM, AMD Athlon 3800 
Dual Core X2, 1GB RAM.

Thanks in advance,

Carl Antaki
[Message sent by forum member 'carcour' (carcour)]

http://forums.java.net/jive/thread.jspa?messageID=211620

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] JDK6 and com.sun.image.codec.jpeg.JPEGCodec compile failure

[Phil Race]

Philip,

Absolutely, You really shouldn't use com.sun.image.codec.jpeg.JPEGCodec.

Code that uses this can't expect to run on all compatible Java
implementations. Image I/O has been around since 1.4 and is
the standard supported solution.

FYI this is quite timely as we are soon to propose at the very least the
complete hiding of this API to new development in JDK 7.
I will send out more email on this sometime soon.

-phil


Roman Kennke wrote:

Hi Philip,


While I understand one should not use this class, a lot of projects still do.


You really shouldn't! ;-)


Under JDK6, the following is actually resulting in a compile failure.
 com.sun.image.codec.jpeg.JPEGCodec is Sun proprietary API and may be removed 
in a future release

Can anyone steer me towards the proper way to outputting a jpeg image if we 
can't use the com.sun.* classes?


javax.imageio.ImageIO.write(image, format, stream) is most likely what
you want.

Cheers, Roman

--
http://kennke.org/blog/

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

[JAVA2D] Retiring the package com.sun.image.codec.jpeg

[Phil Race]

The package com.sun.image.codec.jpeg was added in JDK 1.2 (Dec 1998)
as a non-standard way of controlling the loading and saving of JPEG
format image files.
It has never been part of the platform specification and is not part
of any compatibility test suite and so compatible Java implementations
are not required to include it.
The documentation for it has always been buried under a separate
'other API' heading, clearly distinct from the Java platform API
specification. The intention was to replace it with a standard API.

In JDK 1.4 (FCS/GA 2001) the Java Image I/O API was added
(see JSR-15 at http://jcp.org/en/jsr/detail?id=15) as a standard API.
This resides in the package javax.imageio.
It provides a standard mechanism for controlling the loading and
saving of sampled image formats and requires all compliant Java SE
implementations to support JPEG as per the Image I/O specification.


In JDK 6 to encourage migration to Image I/O several things happened.

1. All documentation of com.sun.image.codec.jpeg was removed
although the classes are still present in *Sun* implementations
- I can't speak for others - and probably only direct Sun licensees
are likely to ship the API assuming they bother to do so.

2. When compiling code using these classes using JDK 6 a warning
is emitted :

warning: com.sun.image.codec.jpeg.JPEGCodec is Sun proprietary API and
may be removed in a future release
   JPEGCodec.createJPEGDecoder(...);
   ^
3.  There were substantial performance improvements to Image I/O
including JPEG, and overall the performance is now very similar
between the two APIs.

So we think its time to retire com.sun.image.codec.jpeg so we
can focus on the single preferred standard API.

However we are aware that applications do still use it, typically
because they were written to run on JDK versions prior to 1.4,

There are several options, not all exclusive :

1. Remove completely in JDK 7 - the most aggressive option.

2. Warn in JDK 7 release notes that it will be removed completely in
JDK8 - this is really just incremental to the existing compilation
warning

3. Make further javac changes in JDK 7 so that the classes are not
located when compiling. ie the compilation warning turns into an error.
Again, with this option the classes *are* still available at runtime so
that code compiled with 1.6 or earlier will still find these classes
and run on JDK 7 This preserves binary compatibility.

4. Remove the classes completely in a release after JDK 7
after a combination of notifications via release notes
and compiler warnings/errors. Ideally this would then
happen in JDK8


Implementing 2+3+4 comes down to using JDK 7 to provide
a further period of grace to migrate and probably provides
the right balance between notice and compatibility (to these
non-standard, unsupported APIs). Particularly since JDK 6
already began this process.

How long does this give people to migrate?
Our historical run rate of releases is one every two years.
JDK 1.2 - Dec 1998
...
JDK 6 Nov 2006
Management may try different models and so forth but I think
that's a good enough estimate which predicts
JDK7 - late 2008
JDK8 - late 2010

Does anyone think they have current code that uses
com.sun.image.codec.jpeg that would have a problem
with this proposed removal?

Any comment on the options?

FYI I am sending this to each of :
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
so many of you may get this message several times.

-Phil Race,
Java 2D.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] new Font() always returns the wrong font

[Phil Race]

Jan Bösenberg (INCORS GmbH) wrote:

Phil,

thanks for the very fast response. For us this bug is not critical,
but since this is a regression, maybe we can see a bugfix introduced
in a JDK 6 update?


I was debating with myself about this one. I'll ask for the OK to
backport it to 6u2

-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] How to get the number of chars represented by a GlyphVector?

[Phil Race]

I do not think its 100% safe. Since there is not necessarily a 1:1 mapping
of glyphs to chars, then some chars may be completely elided away and
have no representation in the returned set from calling this API on each
of the glyph indices. I'd have to check if its universally true but in our
implementation elided away chars typically are replaced by the
special 'invisible glyph', so it may appear to work for that reason,
but that's not guaranteed by spec.

-phil.



Jan Bösenberg (INCORS GmbH) wrote:

Hello again,

I am trying to get the number of chars that a GlyphVector represents The
following line seems to work:

 myGlyphVector.getGlyphCharIndex(myGlyphVector.getNumGlyphs());

The problem is that reading the documentation for getGlyphCharIndex(int
glyphIndex) gives me the feeling that the method should throw an
IndexOutOfBounds exception if the value of glyphIndex equals the number
of glyphs (just like you get an exception when calling
myArray[myArray.length]). But on the other hand it does not explicitly
say that any parameter greater or equal to the number of glyphs will
throw an exception. Can I reliably use the method to determine the
number of chars in a glyph vector or is there a chance that my code will
not work on other VMs or future versions? Maybe the documentation should
be updated to clarify the behaviour? Or is there even a better day to
get the number of chars represented by a glyphVector?


Thanks

Jan

===

To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] new Font() always returns the wrong font

[Phil Race]

Do you mean that the same font installed on other PCs is OK?

Is this XP SP2 ?

Which JDK version?

What does that font say its full name is?
ie font.getFontName()?

Perhaps you could email me the font (just to me please, not the whole list).

But its also possible something is messed up in the windows registry
that's contributing to this. All guesswork at this point.

Oh, and what is the user and system locale on this problem PC?

-phil.

Jan Bösenberg (INCORS GmbH) wrote:

Hello,

on one test system we found a really strange behavious of a little app,
which creates a Font instance for each available font familiy name. The
code looks like this:

 String[] fontFamilyNames =
GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();

 Font[] fonts = new Font[fontFamilyNames.length];
 int fontCount = 0;
 for (int i = 0; i  fontFamilyNames.length; i++) {
   fonts[i] = new Font(fontFamilyNames[i], Font.PLAIN, 1);
 }

On that particular (WinXP) system, there are two fonts installed: Times
New Roman (file name times.ttf) and Times (file name kycw1_75.ttf). Both
family names (Times New Roman and Times) are returned by the
getAvailableFontFamilyNames() method.

The problem is that the line new Font(fontFamilyNames[i], Font.PLAIN, 1)
creates an instance of the Times font for both family names. I tried
using alternative constructors (for example new Font(Map attributes)
with only the FamilyName attribute set), but nothing works. As a result
of this, we simply cannot use Times New Roman on that machine from Java,
which is quite a shame, because it is far better than the Times font
(much more of the Unicode glyphs are covered). If we remove the Times
font from the machine, everything works fine. In non-Java applications
both fonts appear in font choosers (under the names Times and Times
New Roman as you would expect).

I guess this is a bug in the Java font package, but I have a tiny bit a
hope left that there is a workaround available. Can someone help? The
Times font was installed from a driver CD-ROM for a Kyocera printer.


Thanks

Jan

===

To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] new Font() always returns the wrong font

[Phil Race]

I just filed bug 6517861:
Installing font of family Times on Windows hides Times New Roman

I can give you a brief explanation of what's happening but
I don't have a workaround for you.

In jdk 6 we started to use GDI for font lookups for performance
and it looks as if we are running afoul of some hard-coded
alias mappings that windows has in its registry that seems
wrong to me.
Eg I see
Times : Times Roman
Times Roman : Times New Roman
Times New Roman : Times
Wrong in that they should not apply when real fonts of those
aliased names are installed.

In order to be able to report all fonts we call into GDI
and ask it for
1) All font families
2) All fonts in each of those families.

We use the windows API EnumFontFamiliesExW(..)
So in the first case it includes Times in its list
of families and when we then ask for the fonts in that
Times family it reports 5 fonts (!)

Times Roman
Times New Roman
Times New Roman Bold
Times New Roman Bold Italic
Times New Roman Italic

I think that what happens next is that since we see
the family Times after seeing the family Times New Roman
and so GDI's claim that Times New Roman is a member
of the Times family wins. Tnen we pull the plain font
from that family and that's what you get.

Fixing it means adding some extra checking and hoping
GDI plays nice.

-phil.

Jan Bösenberg (INCORS GmbH) wrote:

Hello Alexey,

yes I am using JDK 1.6 (b105). Here is some additional information about
the Times font that I extracted with Microsoft's Font Properties Editor:

Font family name: Times
Version: 19: 34455: 1999
Weight and style: Roman
PostScript name: Times-Roman
Unique name: Agfa:Times-Roman:1999

The other font is the standard Times New Roman that comes with Windows
XP. If there is any other Information that I can provide, just let me know.


Cheers

Jan




Alexey Ushakov schrieb:

Hello Jan,

It seems like a bug. Could you please provide more details concerning
this problem. What version jdk are you using? Did you try jdk6.0 with
your test case?

Best Regards,
Alexey
Java2D Team

Jan Bösenberg (INCORS GmbH) wrote:

Hello,

on one test system we found a really strange behavious of a little app,
which creates a Font instance for each available font familiy name. The
code looks like this:

 String[] fontFamilyNames =
GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();



 Font[] fonts = new Font[fontFamilyNames.length];
 int fontCount = 0;
 for (int i = 0; i  fontFamilyNames.length; i++) {
   fonts[i] = new Font(fontFamilyNames[i], Font.PLAIN, 1);
 }

On that particular (WinXP) system, there are two fonts installed: Times
New Roman (file name times.ttf) and Times (file name kycw1_75.ttf). Both
family names (Times New Roman and Times) are returned by the
getAvailableFontFamilyNames() method.

The problem is that the line new Font(fontFamilyNames[i], Font.PLAIN, 1)
creates an instance of the Times font for both family names. I tried
using alternative constructors (for example new Font(Map attributes)
with only the FamilyName attribute set), but nothing works. As a result
of this, we simply cannot use Times New Roman on that machine from Java,
which is quite a shame, because it is far better than the Times font
(much more of the Unicode glyphs are covered). If we remove the Times
font from the machine, everything works fine. In non-Java applications
both fonts appear in font choosers (under the names Times and Times
New Roman as you would expect).

I guess this is a bug in the Java font package, but I have a tiny bit a
hope left that there is a workaround available. Can someone help? The
Times font was installed from a driver CD-ROM for a Kyocera printer.


Thanks

Jan

===



To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.


===


To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Does printing only support RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR?

[Phil Race]

There's more than one code path but in the typical cases all we do is
send the image to GDI using StretchDIBits. I don't think that supports
specifying an interpolation mode.

-phil.

Jan Bösenberg (INCORS GmbH) wrote:

I am trying to print a buffered image in the print(...) method of a
Printable. The buffered image is scaled to fit the page size, but I do
not seem to be able to control the interpolation type through setting
rendering hints. The print result always looks like nearest neighbor
interpolation is used, which does not look very appealing. Am I doing
something wrong here or does the Graphics object in the print(...)
method only support nearest neighbor interpolation? This is on WindowsXP
professional, JRE 1.6.0


Thanks

Jan

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] PID in sun.awt.image.PNGImageDecoder.produceImage()

[Phil Race]

yes that is what it looks like.

Current CompileTask:
HotSpot Client Compiler: 38  !b
sun.awt.image.PNGImageDecoder.produceImage()V (1772 bytes)

There's an 'XX' option to java which tells hotspot not to compile
a specific method.

I think the syntax is :
-XX:CompileCommand=exclude,sun.awt.image.PNGImageDecoder.produceImage

If that helps then its very probably a compiler bug

If not someone in the VM forums may be able to give you more
ways to diagnose if its really a VM problem or just looks like it

-phil.

Dmitri Trembovetski wrote:

  Hi Mik,

  the crash happened in hotspot (on their compiler thread), not in the
  libraries, so it's hard to say what could be wrong.

  Could you try your applicaion on jdk6?

  Thanks,
Dmitri

On Wed, Nov 22, 2006 at 01:06:07PM +0100, Michele Puccini wrote:
  Hello,
 
  I'm getting the following PID when decoding PNG files.
  The PNG decoding is called from an under pressure rendering thread.
  The crash does not happen if we use our internal (all Java) PNG or TGA
  readers.
 
  What happens ?
 
  Cheers,
 
  Mik
  --
 
  ===
  To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
  of the message signoff JAVA2D-INTEREST.  For general help, send email to
  [EMAIL PROTECTED] and include in the body of the message help.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] AttributedString and Outline (the return of the glyph invaders!)

[Phil Race]

Michele Puccini wrote:

Phil,

so, correct me if I'm wrong, the TextLayout.draw() rasterizes every
single
glyph (and its TextAttributes) to separate images before drawing them
to the
Graphics ?


Yes. That's the way almost all font rendering systems work. The separate
images
are a 'glyph cache'


I can understand the complexity behind glyphs, fonts, graphics and
text, but
.. is there a specific reason why we need to align to the pixel grid ?
Maybe
we would get the same features of the Texlayout by rasterizing
outlines and
effects straight to the Graphics and getting sub-pixel precision.
Maybe not.
Now it's your turn ;)


There is no guarantee that scan conversion by the graphics rasterisation
process
would produce the same results. A simple example is that many TrueType
fonts - especially east asian ones - contain embedded bitmaps. Use outlines
and it will be illegible,
Also this way would be much slower. Go ahead and time drawString()
vs getOutline.fill() .for more than a couple of iterations.

So in summary the difference is expected and understandable.

-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] AttributedString and Outline (the return of the glyph invaders!)

[Phil Race]

First, its not a bug in TextLayout drawString behaves identically.
You can prove this as follows, instead of your AttributedString use

Font fo = new Font(Serif, Font.PLAIN, 12);
fo = fo.deriveFont(AffineTransform.getScaleInstance(2 +
scale, 3));
g.setColor(Color.white);
g.setFont(fo);
g2d.drawString(text, x, y);

Second, text does not scale linearly because of the same hinting
and gridfitting effects I described earlier, and the glyphs are
fitted to the pixel grid and you are specifying fractional point sizes.

FRACTIONAL_METRICS is being specified but that affects only the
accumulation of the advance. It doesn't change the images.
You'd probably see a similar effect with the outline if you
disabled FRACTIONAL_METRICS.


-phil.



Michele Puccini wrote:

Thanks Phil,

I did a little mistake: is not a problem of the outline, which is indeed
correct.
Well, a piece of code is worth a thousand words.

The attached sample shows the animated difference between
TextLayout.draw() and g2d.draw(TextLayout.getOutline). Please give it a
try and see what happens. Is is quite funny to see the glyphs in the
first line jumping one pixel to the other just like the space invaders
in that old arcade game ;)

As you will see from the animation, the glyphs rendered with
TextLayout.draw() jump from one pixel to the other (at int coords ?),
while the glyph outlines are rendered with the expected quality.
Funny enough, the red cursor on the C letter is rendered at float
coords.

So, in my opinion, TextLayout.draw() does not give the expected quality
resuls and this is a pity as it really is very useful.

Cheers,

Mik



ClassX Development Italy  Via Francesca, 368/I I-56030 S.M. a Monte
(PI) 
Tel.(+39)-0587-705153  Fax.(+39)-0587-705153  WEB:
http://www.classx.it  





- Original Message - From: Phil Race [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 16, 2006 1:08 AM
Subject: Re: [JAVA2D] AttributedString and Outline



The bitmap glyph images are hinted and gridfitted.
This is not done for the returned outline as it
doesn't make sense to do that for a pure shape.

For most of what you are doing you need outlines
anyway as the rasteriser can only return glyph
images.

-phil.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Type 1 font measurement

[Phil Race]

Worth a try. 1.6 has some Type1 hinting support that 1.5 lacked.

-phil.

Peter B. West wrote:

On Wed, 2006-11-15 at 16:06 +, Peter B. West wrote:

On Wed, 2006-10-25 at 09:42 +0100, Peter B. West wrote:

On Tue, 2006-10-24 at 11:16 -0700, Phil Race wrote:

Well since we don't look at the AFM file ...

-phil.

Peter B. West wrote:
...

Generally speaking, the logical bounds of characters in Type1 fonts
seems to be slightly smaller than the width given in the AFM file for
that font.

...

Phil,

Plese correct me if I'm wrong, but don't the horizontal metrics in the
AFM file simply reflect the sbw or hsbw commands that are required at
the start of each CharString? For example, when I open a .pfb file,
isolated from its .afm, in FontForge, and look at individual characters,
I get values for left side bearing and for width that are consistent
with the values in the afm file for that font. This is why I'm puzzled
by the differences in Java2D.

These difference make for great difficulties in using 2D to measure text
which will be rendered by some other renderer.

Peter


Sorry about that. Wrong button. I was going to ask if I should bug this,
but it occurs to me that I haven't tried it in 1.6. I'll do that first,
unless you tell me that nothing has changed that is likely to affect
this.

Peter

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] AttributedString and Outline

[Phil Race]

Vincent Hardy's book  Java 2D API Graphics comes with
a GLF toolkit which supports many effects. There are
examples of embossed text and other effects.
I believe the toolkit is available for download.
Use your favourite search engine.

You can also take a look at the java 2D demo.
This does use outlines. Sounds like that isn't
exactly what you want but take a look anyway

Also note that you can set FOREGROUND and BACKGROUND
text attributes which can be a Paint, not just a Color.

-phil.

Michele Puccini wrote:

Hello,

I'm using TextLayouts made by AttributedStrings and I need to outline
(Stroke) the characters. Sadly I didn't find any Outline TextAttribute,
so I
would like to know how to implement it.

More generally it would be nice to implement virtually any kind of
TextAttribute i.e. Emboss, Shadow, etc.

Suggestions ?

Mik
--

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] javax.print.PrintService limitations

[Phil Race]

Jan Bösenberg (INCORS GmbH) wrote:

Thanks (also to Jennifer) for the information. See my comments below

- there is no ServiceUIFactory available for any of my print services


Do you mean the serices returned to you by the JDK?
No, we don't currently support these on the services.
But the principle use for these is if you write your own print service,
its a way to add in its functionalitu to ServiceUI.printDialog(..)
without rewriting it.
What are you trying to do ?


I do not use any custom print services, only the ones returned from the
JDK. Basically I am trying to rebuild the cross platform service dialog
(the one that you create with
PrinterJob.printDialog(PrinterRequestAttributeSet a) ). I have to do
this because the user must be able to select Print All/Print
Selection/Print Page Range, which does not seem to be possible with
the dialogs from the JDK. Creating this dialog is not that difficult,
but while doing this I noticed that the Properties button next to the
print service is always disabled on the JDK's print dialog. So I tried
to improve this for my dialog but found no way of doing this. So in one
sentence, I want the user to be able to open the printer's native dialog
when pressing on the properties button on my own print dialog. But how
do I get the printer's native dialog?


We have an RFE for that one too :)
4673406 Provide a way to display win32 printer driver's dialog

yes, we really should implement that one and it would be returned
as you expect from a ServiceUIFactory.

-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Type 1 font measurement

[Phil Race]

Well since we don't look at the AFM file ...

-phil.

Peter B. West wrote:

We have noticed some oddity in the measurement of Type 1 fonts.
Generally speaking, the logical bounds of characters in Type1 fonts
seems to be slightly smaller than the width given in the AFM file for
that font.

As an example, I have used the luxirr.ttf serif font, converting it to a
pfb file with a corresponding afm, using the wonderful FontForge by
George Williams.

When I get the metrics or, for example A from the ttf file, I get a
width of 1479 in an em box of 2048 square. That is, the single-point
logical width is 1479/2048, or .7221679687.

Obtaining a GlyphVector from the single character A results in the
following measures of logical and visual bounds.

visual
 java.awt.geom.Rectangle2D$Float[x=0.0,y=-0.734375,w=0.71875,h=0.734375]
logical
 java.awt.geom.Rectangle2D
$Float[x=0.0,y=-0.9926758,w=0.72216797,h=1.2036133]

The logical width matches the measurement of the font in FontForge.

Converting the font to a pfb on a 1000 unit em box gives a width of 722,
reflected in the afm file. Running the same test program using the Type1
file gives:

visual
 java.awt.geom.Rectangle2D$Float[x=0.0,y=-0.734375,w=0.71875,h=0.734375]
logical
 java.awt.geom.Rectangle2D
$Float[x=0.0,y=-0.75279236,w=0.716095,h=0.9918213]

The width is .716095. This shrinkage is consistent with observations of
other Type1 files, which have not been converted from ttf, e.g. Adobe's
SY__.PFB Symbol font.

Peter

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] javax.print.PrintService limitations

[Phil Race]

Jan Bosenberg (INCORS GmbH) wrote:

I am currently implementing some printing functionality for our app and
found a number of limitations with javax.print.PrintService.

For example:
- the attributes PrinterMakeAndModel and PrinterInfo never seem to
provide any information


RFE 4673400 Support javax.print.attribute.standard.PrinterMakeAndModel etc.

I am not sure how completely supportable this is. The information
may not be available. But we could implement it where available.



- there is no ServiceUIFactory available for any of my print services


Do you mean the serices returned to you by the JDK?
No, we don't currently support these on the services.
But the principle use for these is if you write your own print service,
its a way to add in its functionalitu to ServiceUI.printDialog(..)
without rewriting it.
What are you trying to do ?



- setting Chromaticity to monochrome still produces color prints on our
color laser printer (and I can select color mode for our black and white
printer)


Not sure about this. Did you check if the service/driver
supported this option? It could be that it does not.


- the PrintQuality attribute never seems to be supported


Is this Windows? On Windows the GDI DEVMODE struct interprets
a positive value in the dmPrintQuality as X resolution instead

quoting MSDN :
dmYResolution
Specifies the y-resolution, in dots per inch, of the printer. If
the printer initializes this member, the dmPrintQuality member specifies
the x-resolution, in dots per inch, of the printer.

so you get resolution OR quality, never both.

If you mean on Unix it depends how we are printing. Its possible
CUPS might expose 'quality' or again it might be 'resolution'
but on unix its likely just not something we can detect


All these limitations are not really severe, but since I have to
implement our own print dialog amyway, I am wondering if they will be
fixed in future or if they are simply a result of the way java accesses
the OS print services. In the last case I could simply omit some options
in our print dialog.

My two simple questions are: Do these limitations only exist on some
systems? And is there are chance that (some of) the limitations of
PrintService will be fixed in Java 7 or 8?


Something of a mixture of the two.

-phil.




Thanks

Jan

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Measuring mixed font text

[Phil Race]

I had a chat with Doug, one of the principal authors of this code.

- The behaviour you see was as I noted intended to account for italic
overhang. If removed then it is possible that lines which end
with italic text may be 'clipped' if hard up against some clipping region.

- However getAdvanceBetween() is supposed to return the logical
advance and did until 1.5 so the behaviour probably should be
reverted.

- But in part the problem arises because getAdvanceBetween()
 is there not to measure substrings. Its there to help you estimate
 line break positions. In fact what you are doing is in general
 not valid because ligatures, optional or required, and combining
 marks mean that drawing the text as substrings may not produce
 the same glyphs or measurement. So a few calls to getAdvanceBetween()
  might be used to find the break point that most closely fits some
  desired width. Then get a TextLayout for the *whole* line.
 Also if you want to fit a  particular known width  line then just
 use getLineBreakIndex().

- We do not really understand the purpose of getting 'fragments'
 It seems to be an unnatural use of this class. Also the many
 calls to getAdvanceBetween() particularly as you apparently
 use it in the first PNG image, probably contribute significantly
to your performance problems,

-phil.

Phil Race wrote:

PS
 You could try compensating by that amount and see if it helps.

I guess I didn't really finish that thought.
I wouldn't compensate in exactly that way - if you did then it
would be ignorant of whether we fixed this API to return
the logical advance as opposed to the visual advance.

What you probably need to adjust by is the difference between this API
and the logical advance as returned by Font.getStringBounds()
for that last character. That way if this API need to fixed it should be
a no-op.

-phil.

Phil Race wrote:

An internal class - TextLine - used by TextLayout and TextMeasurer
is trying to compensate for italic overhang to the right that if
ignored might mean visually text did not fit into the space it
claimed it would occupy.
It only needs to pad the rightmost character in the line this way.
However if you, or TextMeasurer, starts to use these values to
*position* subsequent text then that might well cause the effect
you are seeing.
TextMeasurer.getAdvanceBetween() I think should be logical
advance but I'd need to think about it.
The calculation that's causing your problem is roughly
and usually getAscent() * font.getItalicAngle().

That is what is getting added on to the advance.

You could try compensating by that amount and see if it helps.

-phil.

Peter B. West wrote:

I wrote a couple of small test programs to look at the behaviour of
TextMeasurer, especially in situations where the text is in mixed
fonts.

The fonts I used for the test are from the Luxi font set, available
with
X distributions.

The first one measures  in an italic and in a regular font,
looking at the total advance, the increment of the total advance, and
the advance of the character itself. Results follow.

Ita i 1  adv_to_i 6.364563  increment 6.364563  adv_i_only 6.364563
Ita i 2  adv_to_i 10.80304  increment 4.4384766  adv_i_only 6.364563
Ita i 3  adv_to_i 15.241516  increment 4.4384766  adv_i_only 6.364563
Ita i 4  adv_to_i 19.679993  increment 4.4384766  adv_i_only 6.364563

Reg i 1  adv_0_to_i 4.4384766  increment 4.4384766  adv_i_only
4.4384766
Reg i 2  adv_0_to_i 8.876953  increment 4.4384766  adv_i_only 4.4384766
Reg i 3  adv_0_to_i 13.31543  increment 4.4384766  adv_i_only 4.4384766
Reg i 4  adv_0_to_i 17.753906  increment 4.4384766  adv_i_only
4.4384766

There are a couple of interesting things here. Firstly, the advance of
single characters of the italic fonts is greater than the increment of
characters other than the first, presumably representing an inherent
kerning effect of italic fonts. The increment of subsequent characters
is the same as the advance of the corresponding regular character, as
shown in the lower group of the first set, above.

More interesting is the actual measurement. The ratio of the advance of
the italic character to the advance of its regular peer is 1.43395213!
When I examine the individual characters from the two fonts with
FontForge, I get these values: regular 'a' width 909 LBearing  75
RBearing  5
italic 'a'  width 909 LBearing 123 RBearing -48

The largest difference I can manufacture from those figures is 957/904,
or 1.05862831, which is not in the same ball-park as the TextMeasurer
figures.

The second test repeats the first, with one change. In the first set,
the two inner characters are in the italic font, while the two
outermost
are in a regular font.

Mix i 1  adv_to_i 4.4384766  increment 4.4384766  adv_i_only 4.4384766
Mix i 2  adv_to_i 11.212321  increment 6.7738447  adv_i_only 6.364563
Mix i 3  adv_to_i 15.650798  increment 4.4384766  adv_i_only 6.364563
Mix i 4  adv_to_i 20.089275  increment 4.4384775  adv_i_only 4.4384766

Reg i 1

Re: [JAVA2D] Measuring mixed font text

[Phil Race]

An internal class - TextLine - used by TextLayout and TextMeasurer
is trying to compensate for italic overhang to the right that if
ignored might mean visually text did not fit into the space it
claimed it would occupy.
It only needs to pad the rightmost character in the line this way.
However if you, or TextMeasurer, starts to use these values to
*position* subsequent text then that might well cause the effect
you are seeing.
TextMeasurer.getAdvanceBetween() I think should be logical
advance but I'd need to think about it.
The calculation that's causing your problem is roughly
and usually getAscent() * font.getItalicAngle().

That is what is getting added on to the advance.

You could try compensating by that amount and see if it helps.

-phil.

Peter B. West wrote:

I wrote a couple of small test programs to look at the behaviour of
TextMeasurer, especially in situations where the text is in mixed fonts.

The fonts I used for the test are from the Luxi font set, available with
X distributions.

The first one measures  in an italic and in a regular font,
looking at the total advance, the increment of the total advance, and
the advance of the character itself. Results follow.

Ita i 1  adv_to_i 6.364563  increment 6.364563  adv_i_only 6.364563
Ita i 2  adv_to_i 10.80304  increment 4.4384766  adv_i_only 6.364563
Ita i 3  adv_to_i 15.241516  increment 4.4384766  adv_i_only 6.364563
Ita i 4  adv_to_i 19.679993  increment 4.4384766  adv_i_only 6.364563

Reg i 1  adv_0_to_i 4.4384766  increment 4.4384766  adv_i_only 4.4384766
Reg i 2  adv_0_to_i 8.876953  increment 4.4384766  adv_i_only 4.4384766
Reg i 3  adv_0_to_i 13.31543  increment 4.4384766  adv_i_only 4.4384766
Reg i 4  adv_0_to_i 17.753906  increment 4.4384766  adv_i_only 4.4384766

There are a couple of interesting things here. Firstly, the advance of
single characters of the italic fonts is greater than the increment of
characters other than the first, presumably representing an inherent
kerning effect of italic fonts. The increment of subsequent characters
is the same as the advance of the corresponding regular character, as
shown in the lower group of the first set, above.

More interesting is the actual measurement. The ratio of the advance of
the italic character to the advance of its regular peer is 1.43395213!
When I examine the individual characters from the two fonts with
FontForge, I get these values: regular 'a' width 909 LBearing  75
RBearing  5
italic 'a'  width 909 LBearing 123 RBearing -48

The largest difference I can manufacture from those figures is 957/904,
or 1.05862831, which is not in the same ball-park as the TextMeasurer
figures.

The second test repeats the first, with one change. In the first set,
the two inner characters are in the italic font, while the two outermost
are in a regular font.

Mix i 1  adv_to_i 4.4384766  increment 4.4384766  adv_i_only 4.4384766
Mix i 2  adv_to_i 11.212321  increment 6.7738447  adv_i_only 6.364563
Mix i 3  adv_to_i 15.650798  increment 4.4384766  adv_i_only 6.364563
Mix i 4  adv_to_i 20.089275  increment 4.4384775  adv_i_only 4.4384766

Reg i 1  adv_0_to_i 4.4384766  increment 4.4384766  adv_i_only 4.4384766
Reg i 2  adv_0_to_i 8.876953  increment 4.4384766  adv_i_only 4.4384766
Reg i 3  adv_0_to_i 13.31543  increment 4.4384766  adv_i_only 4.4384766
Reg i 4  adv_0_to_i 17.753906  increment 4.4384766  adv_i_only 4.4384766

Similar observations hold. However, the increment value for the first
italic character following a regular character (the second line of the
upper group) is greater than the advance value for the isolated
character, and greater than any value for the italic only group (upper
group of the first set of observations.)

My interest is that I am using TextMeasurer to perform paragraph line
breaking in situations where I may have mixed-font text. I measure the
complete paragraph, but, in order to perform the line-breaking
algorithm, I need also to know the measurement of individual fragments
of text. Fragments are the pieces between possible break points, which
include spaces and potential hyphenation points.

The effect that I'm seeing (and I haven't yet confirmed that this is
entirely a TextMeasurer problem) is illustrated in the attached
measurement.png. The fragments of the text are placed at offsets from
one another as calculated by their measurements. In the png, the
measurement of a fragment is determined by asking a TextMeasurer,
defined across the whole paragraph, for an advance from the beginning of
the fragment to the beginning of the following fragment. This works
beautifully for the regular text, but the italicised text is, as you can
see, being measured larger than it actually is.

Further, the right margin of the line is extended. This indicates that
the measurement of the entire line differed from the sum of the
individual measurements. I attempted to compensate for this by measuring
fragments as the difference between the total advance from the beginning
of 

Re: [JAVA2D] Measuring mixed font text

[Phil Race]

PS
 You could try compensating by that amount and see if it helps.

I guess I didn't really finish that thought.
I wouldn't compensate in exactly that way - if you did then it
would be ignorant of whether we fixed this API to return
the logical advance as opposed to the visual advance.

What you probably need to adjust by is the difference between this API
and the logical advance as returned by Font.getStringBounds()
for that last character. That way if this API need to fixed it should be
a no-op.

-phil.

Phil Race wrote:

An internal class - TextLine - used by TextLayout and TextMeasurer
is trying to compensate for italic overhang to the right that if
ignored might mean visually text did not fit into the space it
claimed it would occupy.
It only needs to pad the rightmost character in the line this way.
However if you, or TextMeasurer, starts to use these values to
*position* subsequent text then that might well cause the effect
you are seeing.
TextMeasurer.getAdvanceBetween() I think should be logical
advance but I'd need to think about it.
The calculation that's causing your problem is roughly
and usually getAscent() * font.getItalicAngle().

That is what is getting added on to the advance.

You could try compensating by that amount and see if it helps.

-phil.

Peter B. West wrote:

I wrote a couple of small test programs to look at the behaviour of
TextMeasurer, especially in situations where the text is in mixed fonts.

The fonts I used for the test are from the Luxi font set, available with
X distributions.

The first one measures  in an italic and in a regular font,
looking at the total advance, the increment of the total advance, and
the advance of the character itself. Results follow.

Ita i 1  adv_to_i 6.364563  increment 6.364563  adv_i_only 6.364563
Ita i 2  adv_to_i 10.80304  increment 4.4384766  adv_i_only 6.364563
Ita i 3  adv_to_i 15.241516  increment 4.4384766  adv_i_only 6.364563
Ita i 4  adv_to_i 19.679993  increment 4.4384766  adv_i_only 6.364563

Reg i 1  adv_0_to_i 4.4384766  increment 4.4384766  adv_i_only 4.4384766
Reg i 2  adv_0_to_i 8.876953  increment 4.4384766  adv_i_only 4.4384766
Reg i 3  adv_0_to_i 13.31543  increment 4.4384766  adv_i_only 4.4384766
Reg i 4  adv_0_to_i 17.753906  increment 4.4384766  adv_i_only 4.4384766

There are a couple of interesting things here. Firstly, the advance of
single characters of the italic fonts is greater than the increment of
characters other than the first, presumably representing an inherent
kerning effect of italic fonts. The increment of subsequent characters
is the same as the advance of the corresponding regular character, as
shown in the lower group of the first set, above.

More interesting is the actual measurement. The ratio of the advance of
the italic character to the advance of its regular peer is 1.43395213!
When I examine the individual characters from the two fonts with
FontForge, I get these values: regular 'a' width 909 LBearing  75
RBearing  5
italic 'a'  width 909 LBearing 123 RBearing -48

The largest difference I can manufacture from those figures is 957/904,
or 1.05862831, which is not in the same ball-park as the TextMeasurer
figures.

The second test repeats the first, with one change. In the first set,
the two inner characters are in the italic font, while the two outermost
are in a regular font.

Mix i 1  adv_to_i 4.4384766  increment 4.4384766  adv_i_only 4.4384766
Mix i 2  adv_to_i 11.212321  increment 6.7738447  adv_i_only 6.364563
Mix i 3  adv_to_i 15.650798  increment 4.4384766  adv_i_only 6.364563
Mix i 4  adv_to_i 20.089275  increment 4.4384775  adv_i_only 4.4384766

Reg i 1  adv_0_to_i 4.4384766  increment 4.4384766  adv_i_only 4.4384766
Reg i 2  adv_0_to_i 8.876953  increment 4.4384766  adv_i_only 4.4384766
Reg i 3  adv_0_to_i 13.31543  increment 4.4384766  adv_i_only 4.4384766
Reg i 4  adv_0_to_i 17.753906  increment 4.4384766  adv_i_only 4.4384766

Similar observations hold. However, the increment value for the first
italic character following a regular character (the second line of the
upper group) is greater than the advance value for the isolated
character, and greater than any value for the italic only group (upper
group of the first set of observations.)

My interest is that I am using TextMeasurer to perform paragraph line
breaking in situations where I may have mixed-font text. I measure the
complete paragraph, but, in order to perform the line-breaking
algorithm, I need also to know the measurement of individual fragments
of text. Fragments are the pieces between possible break points, which
include spaces and potential hyphenation points.

The effect that I'm seeing (and I haven't yet confirmed that this is
entirely a TextMeasurer problem) is illustrated in the attached
measurement.png. The fragments of the text are placed at offsets from
one another as calculated by their measurements. In the png, the
measurement of a fragment is determined by asking a TextMeasurer,
defined across

Re: [JAVA2D] Kerning

[Phil Race]

Peter B. West wrote On 08/15/06 04:29,:


What's the situation with kerning?

Can I assume that kerning is not supported on Type1 fonts? If so, are
there any plans to enable the reading of afm files associated with Type1
fonts to obtains kerning data?




Not supported and there are no plans.


Even with truetype fonts, I don't seem to get any result from setting
the KERNING attribute to KERNING_ON. I've tried generating
AttributedStrings using both FONT_FAMILY, etc, and using an instance of
FONT. No difference. Is there a secret?




It should work, assuming you are letting JDK do the layout. I know you
were using
GlyphVector. 'Font.layoutGlyphVector' should apply the kerning but
createGlyphVector()
doesn't process the text and just assigns default advances so maybe
that's your problem?

-phil.


Peter

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Kerning

[Phil Race]

If its not working for TextLayout then there's not much point looking at
GlyphVector.
I suggest to try using Times New Roman or perhaps Arial directly with
TextLayout
This definitely works fine and if there's still no kerning you probably
have a bug in your code.

-phil.

Peter B. West wrote On 08/15/06 06:35,:



I ran some quick tests using a LineBreakMeasurer and TextLayout. Text
was New wave away WAVE AWAY, which should show some variation. The
advance of the layout did not vary.  I'll have a look at the
GlyphVectors.

Peter





===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] ZWJ and ZWNJ

[Phil Race]

I assume this means that neither will ever occupy any rendering space.

It will likely depend on the font. If the font maps it to a zero width
glyph then yes
But if the font doesn't map it, and since JDK doesn't treat it
specially, then it'll end up mapped to the missing glyph
just like *any* character you try to display that's not present in the font.
and the mssing glyph usually does occupy space.

but hopefully you will only be using fonts that map these ..

What's the effect of ZWNJ and ZWJ on ligatures?

http://www.unicode.org/standard/versions/Unicode3.0.1.html#Ligatures

states :
 ZERO WIDTH  NON-JOINER

The intended semantic is to break both cursive connections and ligatures
in rendering.

ZERO WIDTH JOINER

is more complex .. but it encourages ligatures that would not otehrwise
be formed
please check out URL above


-phil.

Peter B. West wrote:

Doug noted earlier that the implementation supports 0x200C (ZERO WIDTH
NON-JOINER) and 0x200D (ZERO WIDTH JOINER). Not supported (along with
ZWSP) is WORD JOINER 0x2060. I assume this means that neither will ever
occupy any rendering space.

What's the effect of ZWNJ and ZWJ on ligatures? Will either or both
prevent the formation of ligatures?

Thanks
Peter

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] More on ZWSP and SHY

[Phil Race]

Peter,

RFE was probably right. But its moot for 1.6 as we are in the very final
stages of
stabilising the release so unless it can be shown to be a regression
(something that
used to work in 1.5 but now doesn't) it too late.

-phil.

Peter B. West wrote:

On Tue, 2006-07-04 at 13:12 -0700, Doug Felt @ Sun wrote:


Peter:

Please file bugs on both issues.

There are a few characters we special case when converting to glyphs -
tab, cr, lf are it in the ASCII range, and we also filter bidi control
characters and some other formatting characters.  Everything else goes
through the regular font CMAP, and if the font maps it, most of the time
it will provide the missing glyph for these characters. If the font
doesn't map the character at all, we use the missing glyph.  The missing
glyph typically looks like an empty rectangle.

Currently the characters we map ourselves are the following.

0x0009, 0x000A, 0x000D,
0x200C, 0x200D, 0x200E, 0x200F,
0x2028, 0x2029, 0x202A, 0x202B, 0x202C, 0x202D, 0x202E,
0x206A, 0x206B, 0x206C, 0x206D, 0x206E, 0x206F

You'll note we don't currently handle ZERO WIDTH SPACE (U+200B)...

This is an implementation detail, of course, and some vendors (Apple, in
particular) probably do something different.  This is just FYI.

Doug



Doug,

I think I made a little mistake. I've put both of these in as RFEs,
which I (now) assume means they won't be considered for 1.6. Should I
change these to bugs when the opportunity arises?

Peter

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] More on ZWSP and SHY

[Phil Race]

Peter B. West wrote:


Some examples of the handling of ZWSP and SHY.

LineBreakSample1.png was created with LineBreakSample1.java. No ZWSP or
SHY.

LineBreakSample2.pngLineBreakSample2.java. There's a ZWSP in
Vin[]cent. Note the extra space in the layout, but no special character
marking.

LineBreakSample3.pngLineBreakSample3.java. There's a ZWSP in
Vin[]cent, and an SHY in bril-liance.  Note the special character
marking ZWSP in the layout.
Note that the SHY is visible. The font is Luxi Serif Regular.

I realize there is some controversy about the handling of SHY, but, for
better or worse, Unicode now wants it treated as a hint that is
invisible except at at lien break, IIUC.






The ZWSP handling is probably relying on the font mapping it.
I thought we should be handling it in any case. This needs some digging.
You could perhaps (in this case) use the JRE's Lucida Sans Regular which
is a superior
superset of the Luxi font and does map it.

But I don't think we'd claim to handle the SHY (Soft Hyphen) in the way
you want.


-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Measuring oblique fonts

[Phil Race]

I don't know of any problems measuring italic fonts.
I suspect its a bug in your code but have no idea what.
Also the zero width spaces should be mapped to an invisible glyph id
but I don't know how you are creating the glyph vectors.
I can't imagine anything other than a *small* complete sample program
will help
understand this.

-phil.

Peter B. West wrote:


How do I measure the boundary of oblique text? When I layout upright
text using a combination of logical and visual bounds, I get great
results. When I use the same algorithms on the oblique version of the
font, my measurements are all over the place like a dog's breakfast.
It's not just the lean on the last character of the line. I'm missing
one or two characters completely.

The curious thing is that where I end a line with a hyphen, the
measurement is OK.

The line is constructed from a series of GlyphVectors, one per word or
word fragment, where a word contains a hyphenation point. (The artifacts
in the text are the font's representation of a ZWSP, much to my
disappointment.)

Any suggestions?

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.










===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Font instances

[Phil Race]

Peter B. West wrote:


I have a requirement for accurate measurement of text to generate a
layout in one part of a work flow, and the rendering of the text in a
later part of the workflow, using the same fonts. For example, I layout
text to be rendered later in PDF.

For this to work, I need to know that the font I specify for the layout
will be the same font used for the rendering. I have to avoid font
substitutions or aggregations that cannot be expected to occur in the
renderers.

Some random observations:

I can get an array of Font[] from the GraphicsEnvironment, but that is
time-consuming, especially if this occurs on a document by document
basis. Can I get a single font that is the same as a particular element
of the array returned by getAllFonts(), by using the fontName returned
from one of the array fonts, via the decode method?





I occasionally see people trying to use Font.decode() where there's really
no need.

If you want to use Arial then just do :

Font f = new Font(Arial, Font.PLAIN, 12) ?

I don't see what's hard about this.

It  takes longer to parse the string to decode than to directly create this
object for you and its less error prone.


As I understand it, the fonts returned from gatAllFonts may include
composite fonts.


*WILL* include.


hasUniformLineMetrics will tell me about some aspects
of the consistency of the font If susbstiution have occurred which
happen to share the same height (for LR/RL scripts) characteristics, I
as but will it notify me only about variations in the height (for LR/RL
scripts)?

I can createFont from a font file to which I have access. If I try to
register that font, I may have a name clash with an existing system
font. In fact, if I am picking up a font file from a known location,
that is guaranteed, isn't it?




Yep, and API for registering these is new 1.6 functionality anyway


Can I use such an instance of a created font in an attribute map to
getFont(Map)?




Not unless its a non-clashing one that you register

and why are you using getFont instead of the constructor that takes a Map?


Can I further use such a Font instance in deriveFont methods?




Unless registered  (via new 1.6 API) Fonts created with createFont can
*ONLY* be used by deriveFont
methods.



What's the best approach?



directly create the font you want :

Font f = new Font(Arial, Font.PLAIN, 12) ?

-phil.


Thanks
Peter

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Using GlyphVectors

[Phil Race]

Peter B. West wrote:


On Thu, 2006-06-15 at 17:24 +0100, Peter B. West wrote:



David,

Thanks for the response.  I did look at LineBreakMeasurer, but in looks
as though the most powerful layout mechanism available is
Font.layoutGlyphVector. The docs say:




its not 'the most powerful'


Returns a new GlyphVector object, performing full layout of the text if
possible. Full layout is required for complex text, such as Arabic or
Hindi.

It was that flexibility and power I was after. You have to do your own
Bidi which is a complicationg factor, but you get everything else, as
far as I can tell.




as you say it doesn't do Bidi and as David Kavanagh as trying to remember
AttributedString can handle text in multiple fonts (ie suppose you wnat
to style
one word in italics,) and with various stylings (have a word in red or
have it underlined)
AttributedString together with LineBreakMeasurer can handle that. It
will also handle Bidi


I'm using AttributedString as well, with subclasses of
AttributedCharacterIterator.Attribute for hyphenation markers and
character replacement graphics.

Full layout is an expensive process, so I would like to be able to work
off the GlyphVectors I have, if possible, to retrieve the broken lines.







you get most of the same benefit by caching the TextLayout objects that
LineBreakMeasurer
returns. Mostly apps should avoid GlyphVector unless you know you can
make some
simplifying assumptions about the text you will be handling.

So my feeling is you are digging into the guts rather than using the
higher level APIs
that have been designed for this sort of purpose.

I am not sure if you are also wanting to somehow break at hyphens or
have some
special behaviour associated with them. LineBreakMeasurer could also do that
by telling calling the overload of LBM.nextLayout() that takes offSetLimit.

-phil.


This seems to be a silly idea on reflection.  The whole point of doing
complex layout is that it accounts for all sorts of context
dependencies. This would show up most glaringly when hyphenation occurs.
It seems to me now that I may need to perform GlyphVector layout on a
word-by-word basis, and to get separate GlyphVectors or the hyphenated
components of words.

Any other suggestions?

Peter

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] GlyphVectors

[Phil Race]

For text display issues where you are using using the Graphic2D class
and TextLayout
and GlyphVector this is the right place.

But there is a Java Internationalization forum
http://forum.java.sun.com/forum.jspa?forumID=16
which may be a more appropriate forum for other text processing questions

-phil.

Peter B. West wrote:


Is this the right place to ask questions concerning GlyphVectors and
other text-processing components which may overlap with I18N?

Peter

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Black and White printing

[Phil Race]

Perhaps you could create a BufferedImage.TYPE_BYTE_BINARY with a 2 color
IndexColorModel
and have all the printing go into there. Then all rendering will have to
be one of those two colours
which I assume you would select as BW.

The drawbacks to this are that to get printer resolution graphics
(something you also
were seeing problems with already) that BufferedImage will need to be
big and you
will have to scale it appropriately and the resulting spool file will
also be huge.
Another drawback is that it may not look very pretty.

In any case I don't see a way to do this via the printing APIs.

-phil.

[EMAIL PROTECTED] wrote:


Phil,

I'm still puzzled.  It isn't clear how to accomplish what I want.  If I was in 
a color lookup world I would do something like:  set 0 - white and colors 1-256 
to black.  The problem with monochrome printing is the user has a yellow line 
drawn and wants to print it on a black and white printer.  If I use grayscale 
it comes out as a faint line on the paper.  When it copys this or puts it on a 
viewfoil it is very faint and noone can read it.  So the need for Black and 
White.
[Message sent by forum member 'diverdad' (diverdad)]

http://forums.java.net/jive/thread.jspa?messageID=116324

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Black and White printing

[Phil Race]

Do you mean you want to update the list of choices the user sees for
some reason?
The dialog is not customisable in this way so you'd have to write your
own dialog.

Also I wonder how you expect to communicate this intent to the printing
API and ultimately
to the printer driver
For example, on windows you can tell the printer driver to use either
Monochrome
or Color (assuming its color capable) via a GDI DEVMODE setting. There's
no additional BW setting.
So if for some reason your purpose is to have a purely bilevel output
rather than printing
in shades of grey via half-toning or the like, then I don't see how to
do this except to
control the actual colors that are used and limit them to black and white

So monochrome *IS* BW - ie use only black ink and the printer just
dithers the black ink
to achieve the perception of grey levels (unless you have a rare printer
which has grey inks)

-phil.


[EMAIL PROTECTED] wrote:


I only know about printing from the tutorial and using it as a service.  I want 
to add to the print menu : Black and White to the picks already there of 
Monochrome and Color.  What is best way to do this.
[Message sent by forum member 'diverdad' (diverdad)]

http://forums.java.net/jive/thread.jspa?messageID=116265

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Printing Resolution

[Phil Race]

I suspect you are printing a double-buffered swing component window
using paint().
That paints to the swing back buffer which is unsurprisingly at screen
resolution
and then that is what you are sending to the printer.

Use Component.printAll() to print a Component, *not* Component.paint().

-phil.

[EMAIL PROTECTED] wrote:


How do I take advantage of the full resolution of the printer?  When I do a 
default print using the printer service I seem to get the resolution of the 
window that I am printing, is there some way of getting the resolution of the 
printer not that of the display device?  I have a Java2D graphics window, and 
have tried the following with no success:

  Graphics2D graphics2D = (Graphics2D) graphics;

  // Scale the printout to fit the pages.
 double scalex = format.getImageableWidth() / getWidth();
  double scaley = format.getImageableHeight() / getHeight();
  double scale = Math.min(scalex, scaley);
  // translate to the printable (0,0) location on the paper.
  graphics2D.translate((int) format.getImageableX(),
  (int) format.getImageableY());
  graphics2D.scale(scale, scale);
  // then paint the graphics 2D object.


I still get jagged lines on the printer device.  The original window maybe 
displayed at 600x600.
[Message sent by forum member 'diverdad' (diverdad)]

http://forums.java.net/jive/thread.jspa?messageID=116274

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Black and White printing

[Phil Race]

I want the background to be white and all drawings to be black

So you need to proceed as I advised but the new dialog seems like a lot
of work
for little gain. We can't add it in our dialog as we can't control the
colours you use.

-phil.


Yes I understand that I need to display a new dialog.  Black and white is not 
the same as monchrome.   With monochrome you get shades of gray.  I want the 
background to be white and all drawings to be black.
[Message sent by forum member 'diverdad' (diverdad)]

http://forums.java.net/jive/thread.jspa?messageID=116301

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] BreakIterator example

[Phil Race]

Peter,

First the delay in getting any response is because this isn't a Java2D
question so I don't
think there's a whole lot of expertise on this list in this area.

I am informed that a better place to have asked this question would have
been :

http://developers.sun.com/contact/feedback.jsp?category=j2semailsubject=Internationalization%20(I18N)

which I agree is obscure.

Anyway I asked the experts and the response I received was:

And for the break iterator question, assuming that s/he refers to a
non-letter supplementary character
by a non-letter surrogate, I think the code happens to work even
though the loop is doing p++,
since a stand alone surrogate code point is always non-letter.  So it
just skips the low surrogate in the loop.

For further clarification I suggest the above mentioned web form.

-Phil.

Peter B. West wrote:

The BreakIterator description contains the following example.\
quote
 Find the next word:

 public static int nextWordStartAfter(int pos, String text) {
 BreakIterator wb = BreakIterator.getWordInstance();
 wb.setText(text);
 int last = wb.following(pos);
 int current = wb.next();
 while (current != BreakIterator.DONE) {
 for (int p = last; p  current; p++) {
 if (Character.isLetter(text.codePointAt(p))
 return last;
 }
 last = current;
 current = wb.next();
 }
 return BreakIterator.DONE;
 }
/quote

In the inner for loop, what happens if a non-letter surrogate is found?

Peter
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/

===

To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] BreakIterator example

[Phil Race]

Phil Race wrote:


Peter,

First the delay in getting any response is because this isn't a Java2D
question so I don't
think there's a whole lot of expertise on this list in this area.

I am informed that a better place to have asked this question would have
been :

http://developers.sun.com/contact/feedback.jsp?category=j2semailsubject=Internationalization%20(I18N)


which I agree is obscure.


PS .. I was just informed of a Java Internationalization forum :
http://forum.java.sun.com/forum.jspa?forumID=16

that's the real best place for this question

-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] JTextField in one Rectangle....

[Phil Race]

[EMAIL PROTECTED] wrote:


thanks for help Dmitri
an other help..
if is possible know the dimensions of a A4 sheet





What a strangely unrelated question :)
The dimensions of an A4 sheet is specified by the International Standards
Organisation (ISO, hence ISO A4).  So if you just want to know that then
there's plenty of resources on the web

here's a good informative link from googling and feeling lucky ...

http://www.cl.cam.ac.uk/~mgk25/iso-paper.html

But somehow I don't think you asked the question you really wanted to ask

My best guess is what you REALLY meant to ask, is if there is anywhere
in JDK  that we have these constant values stashed and yes, you can consult
javax.print.attribute.standard.MediaSize.ISO.A4

-phil.


rabbit
[Message sent by forum member 'rabbit1978' (rabbit1978)]

http://forums.java.net/jive/thread.jspa?messageID=103997

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.




===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Using an OpenType font

[Phil Race]

We do not support OpenType fonts - ie CFF fonts in a TrueType wrapper,
There is an open RFE which addresses it.
RFE: T2K should be used to rasterize CID/CFF fonts
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4356282

But that won't be addressed until at least the next major release
after mustang (1.6) which puts it at least a couple of years away.

-phil.

[EMAIL PROTECTED] wrote:

I am having some difficulty using an Adobe OpenType font in my application.  
I've tried the two routes I could come up with, via the constructor and static 
createFont api.

  It seems the format is unrecognized by the createFont method; and I am 
wondering how I could go about massaging the font file to a format that is 
expected.

  I realize this may not be simple; but I thought I'd give it a try anyway.  
Thanks.
[Message sent by forum member 'raykroeker' (raykroeker)]

http://forums.java.net/jive/thread.jspa?messageID=101091

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Java font interaction with Adobe fonts

[Phil Race]

You can run the app with the flag -Dsun.java2d.debugfonts=true to see which
font files are accessed by 2D. But you may have a lot to wade through if the 
problem
is that some font we expected to find is missing, as likely we will open all 
files.
Still you may get a clue.
Another approach is that if it is really similar to the Symbol issue then the 
problem,
it really ought to be a font that is named in the fontconfig.properties file 
AND is
also a Postscript font. You can see which fonts are expected by looking for 
lines
like this :
filename.Arial=ARIAL.TTF
filename.Arial_Bold=ARIALBD.TTF
filename.Arial_Italic=ARIALI.TTF
filename.Arial_Bold_Italic=ARIALBI.TTF
filename.Symbol=SYMBOL.TTF
filename.Wingdings=WINGDING.TTF

The Symbol entry is what caused the previous problem
I am sure I would expect to find a PS font of the same name as any of the other
fonts as most of them are proprietary names from Monotype .. so Adobe would 
likely
not re-use them.

PS .. The Type 3 bug doesn't seem like to be relevant.

-phil.

[EMAIL PROTECTED] wrote:

A while back Phil helped me figure out why certain fonts were displaying oddly 
(incorrect height calculation) in Java:

http://forums.java.net/jive/thread.jspa?threadID=8666tstart=0

The root was that Adobe software had installed an PostScript Symbol font 
(SY_.PFM) into the Windows Fonts directory, and had removed the Symbol.TTF 
font file.

Now we've got a customer who has a whole bunch of Adobe software, and a whole 
bunch of *.PF* files installed in his fonts directory, and has the same 
problem, and restoring his Symbol.TTF file doesn't solve it.

Removing ALL the *.PF* files does solve the problem; but is there any 
alternative to this? I.e., is there a way to know which subset of the fonts are 
the cause?

I found this Sun bug fixed in Mustang:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192865

but that mentions ignoring Type 3 fonts, which doesn't apply in this case, 
right?

Thanks!

Jared
[Message sent by forum member 'jaredmac' (jaredmac)]

http://forums.java.net/jive/thread.jspa?messageID=99225

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

[JAVA2D] another test message to be deleted

[Phil Race]

testing cross posting between the list and the java.net 2D forum

-phil.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] layoutGlyphVector

[Phil Race]

1. Yes that's a bad javadoc closing tag placement.

2. What it is trying to say is that if you have text that needs Bidi,
then use the java.text.Bidi analysis to
break it into runs, each of which can then be used with
layoutGlyphVector. This does mean you'd
have multiple GVs you'd have to draw individually.

3. This may seem tricky but 99.99% of apps don't go near here .. it was
only added in 1.4
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4403152
has some background on this relatively recent origin of layoutGlyphVector.

So most apps use drawString will automatically handle Bidi by under the
covers invoking TextLayout.
In fact a lot of typical desktop apps don't even call drawString
directly : they set text on a Component.

-Phil.

Peter B. West wrote:

The API docs for java.awt.Font.layoutGlyphVector(...) have a slight bug.
The underlying text reads:
-quote-
DDReturns a new codeGlyphVector/code object, performing full
 layout of the text if possible.  Full layout is required for
 complex text, such as Arabic or Hindi.  Support for different
 scripts depends on the font and implementation.
 p
 Layout requires bidi analysis, as performed by
 codeBidi/code, and should only be performed on text that
 has a uniform direction.
-endquote-

This is confusing.  It says that layout requires bidi analysis, but then
appears to be saying that if, following this analysis, there is any
mixed bidi text, you can't use layoutGlyphVector. Is this correct? Does
this mean that I must perform the bidi analysis, then iterate through
the paragraph, calling layoutGlyphVector on each of the fragments in
turn?

Peter
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
---
[This E-mail has been scanned for viruses but it is your responsibility
to maintain up to date anti virus software on the device that you are
currently using to read this email. ]

===

To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Return of the Killer Glyph - How one glyph kills them all

[Phil Race]

For that character we are reporting a vertical advance as well as an horizontal 
advance.
There seem to be a few in wingdings that do so - probably those you identify.
It would take some digging to see if we are reporting correctly.

-phil.

Jan Bösenberg (INCORS GmbH) wrote:

Yesterday I ran into an amazing behaviour in glyph rendering. This
probably qualifies as a bug, but in any case it is really weird.

In a few words, if one certain glyph is displayed in a JTextField (or
generally in Swing text), it will kill all trailing glyphs (or at least
make them disappear)! This probably only works on Windows (I tested this
on WinXP running JRE 1.6b66 and JRE 1.5), because Wingdings must be used
for the characters uf000 - uf0ff.

So if you are running Windows, simply run the attached test class. When
you press on the button, character uf0ea, which is rendered using the
Wingdings bold arrow down, will be inserted at the beginning of the
text in the JTextField (it should be a bold down arrow, otherwise you
probably will not see the effect). Suddenly all trailing characters
disappear. If you remove the character (simply by editing the
JTextField), the characters will reappear. Isn't this weird? And if you
select the killer glyph, only the directly following glyph will be visible.

What actually seems to happen is that the followings glyphs are still
there, but they are shifted up, outside of the visible rect of the
JTextField. And there are other glyphs in Wingdings, that can shift the
trailing glyphs down (for example uf0ea), neutralizing the effect. And
using two of the glyphs shifts the trailing chars twice (so you need two
gylphs shifting into the other direction to neutralize the effect). This
has probably something to do with the inserted glyph's baseline, but it
is strange that the leading glyphs are displayed normally.

I have seen similar effects with our text editor in some cases, when
whole lines were shifted behind some weird glyphs, but this is the first
time that I found something that I can actually put my fingers on.
Actually I am not really sure what to make of this. Is it the correct
behaviour from an engineer's point of view (it certainly is not from a
user's point of view). Is it a bug? Should I file a bug report? Also, is
this a Java2D related issue, or is the Swing team responible here?

Cheers

Jan




* start of test class *

import javax.swing.*;
import java.awt.*;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;

public class KillerGlyphTest {

  public static void main(String[] args) {
final JTextField textField = new JTextField(Text to be killed);
JButton button = new JButton(Insert Killer Glyph);
button.addActionListener(new ActionListener() {
  public void actionPerformed(ActionEvent e) {
// We simply insert one character at the beginning of the text
textField.setText('\uf0ea' + textField.getText());
  }
});
// add button and text field to a panel
JPanel panel = new JPanel(new BorderLayout());
panel.add(textField, BorderLayout.NORTH);
panel.add(button, BorderLayout.CENTER);
// create a frame and show it
JFrame frame = new JFrame(Return of the Killer Glyph);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setContentPane(panel);
frame.setSize(300, 100);
frame.validate();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
  }

}


* end of test class *


Just for completeness, here is an incomplete list of glyphs from
Wingdings that show a similar behaviour (as you can see they are all
gylphs used for to display up/down metaphor):

- uf0e9 (shifts trailing text down, this can neutralize uf0ea)
- uf0ce (shifts trailing text down)
- uf0cf (shifts trailing text up)
- uf0dd (shifts trailing text down)
- uf0de (shifts trailing text up)
- uf0f1 (shifts trailing text down)
- uf0f2 (shifts trailing text up)
- uf047 (shifts trailing text down)
- uf048 (shifts trailing text up)

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Printing multipage tiff file.

[Phil Race]

Probably the best and most straightforward thing to do is
scale the image to fit on a single page.

-phil.


Jorge wrote:

 Hi

I wrote a small applet, that handles tiff files. It zooms, rotates and
so on. There is only one more feature I need and that is printing. So
far I manage to print individual pages by printing the image which is
fine when the tiff file contains a single page. But when is a multipage
tiff file. I end up sending multiple printjobs to the printer. Is there
a better wat to print multipage tiff files?

Thanks

Jorge



===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body of the message signoff JAVA2D-INTEREST. For general help, send
email to [EMAIL PROTECTED] and include in the body of the message
help.


===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] drawString() on Graphics2D question

[Phil Race]

Time for a few quick comments
 Alternatively you can convert the string to a Shape and perform
you will get worse looking text this way. It will also be much slower.
 Another alternative (preferable to creating a Shape, I think) is
 to render the string into an Image, and then rotate the image.
As well as the string itself an image will carry the background
with it so this is probably not the best way to go for most people.
And except for quadrant rotations I would not expect great results.
Rotate the graphics and draw the text along the lines of a previous
poster is the most straightforward solution and that will get
accelerated too in the future and is fairly snappy even in software.
As for measuring the text, there are many APIs for this - too many!
But the only one that is trying to be pixel perfect is
java.awt.font.GlyphVector.getPixelBounds() which is however consequently
expensive and won't work for complex text. Try to use something like
java.awt.font.TextLayout.getBounds() for that - its not going to
be as pixel perfect but will work for complex text.
You may even be able to get away with
java.awt.font.GlyphVector.getVisualBounds() if you don't use complex
text. Did I mention there are a lot of APIS for this? In fact I
probably still missed one ..
-phil.
Chet Haase wrote:
Another alternative (preferable to creating a Shape, I think) is
to render the string into an Image, and then rotate the image.
Or better yet: render the rorate string into the image, and then
just copy the image (no transform involved).
This approach is not worth the hassle if you are constantly
changing the string orientation, or if you are only rendering it
once.  Butif you are constantly rendering the same string
at the same orientation, then it might be worth the hassle/
memory-footprint tradeoff to get a performance boost from
doing a simple image copy instead of a transformed text
operation.
Worth mentioning as an option, anyway.
Chet.
Alexey Ushakov wrote:
I think that first approach is more preferable.
Shape of the string is just outline of the string. It does not contain
all
necessary information (like hinting for example) for drawing string.
This could affect quality especially in case of strings of small sizes.
Though, such approach could be used with strings of large sizes for
performance reason.
Alexey
On Tue, Mar 22, 2005 at 10:32:27AM -0500, Nidel, Mike wrote:
The answer to your first question is relatively simple:
Before you draw the string, you can do a transform() on the
Graphics2D. You pass in an AffineTransform that you create
with AffineTransform.getRotateInstance(theta).
Alternatively you can convert the string to a Shape and perform
a rotation on the Shape itself.
As for your second question, I don't think I can help you there.
This information will change depending on whether you're using
anti-aliasing or not. You may be able to convert your string
into a Shape and do some kind of operation to iterate over all of
the pixels in the shape... but I'm not sure.
Mike

-Original Message-
From: Discussion list for Java 2D API
[mailto:[EMAIL PROTECTED] Behalf Of Sven Mielordt
Sent: Tuesday, March 22, 2005 10:21 AM
To: [EMAIL PROTECTED]
Subject: [JAVA2D] drawString() on Graphics2D question
Hi fellows,
I have a short question concerning drawString() on Graphics2D.
When using it, the string is printed horizontally.
But how can I print text vertically or at arbitrary angles???
A refining question concerns the number of pixels needed for
the string.
Is there any method to find out how many pixels in all
directions will be occupied?
Thank you,
Sven
__
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
==
=
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body
of the message signoff JAVA2D-INTEREST.  For general help,
send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Print Spool Issue

[Phil Race]

hmm .. that sounds excessive.
Particularly the 3X expansion for the 4200.
I also doubt (from your description of what you are printing)
that is anything under our control.
Unless we draw the whole page as a big raster the device resolution
shouldn't make any difference to us.
As Karen suggested its possible its something about the way you have
configured the printer driver.
Perhaps its set to always download the font rather than using
printer fonts?
The gif shouldn't do this from the size you quote and filled
rectangles shouldn't do it either.
A good experiment would be to eliminate each of these in turn to
see if it makes a massive difference.
But there are some things that can trigger text to be less efficient ..
are you using drawString or TextLayout.draw(..)?
If using the latter I'd urge you to try JDK 1.5 as that should help
a lot.
BTW I *HOPE* you are using either that or 1.4.2 already ..
-phil
Justin W wrote:
Hi Everyone,
I've created what I thought was going to be a relatively easy application
to send 5 page print jobs to printers throughout our company. I am getting
extremely large spool files and it is causing serious performance
problems. Using a Windows 2000 server, printers are HP LaserJet 4100 and
4200 using PCL 6 drivers. Spool sizes on the 4100 are ~4MB and on the 4200
they are in excess of 12MB.
The pages contain mostly text, a small (3k) gif on one page, and some
various rectangles drawn on 3 of the 5 pages. Fonts are all Arial with
sizes from 7-12. It is a black and white document containing no alpha that
I know of. I've tried writing the job to an offscreen image as specified
here:
http://java.sun.com/products/java-media/2D/forDevelopers/java2dfaq.html#spool
but the quality was very bad and the spool size was larger.
Any ideas?
Thanks in advance,
Justin
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Print Spool Issue

[Phil Race]

posting the answer on this to the list for the record :
It turned out that Justin was using TextLayout extensively
and when he tried JDK 1.5 the spool file size came down to a
very acceptable 450K
This is because of the 1.5 fix to:
 Bug ID: 4480930
 Synopsis: Java 2D printing : TextLayout prints as filled shapes.
-phil.
Phil Race wrote:
hmm .. that sounds excessive.
Particularly the 3X expansion for the 4200.
I also doubt (from your description of what you are printing)
that is anything under our control.
Unless we draw the whole page as a big raster the device resolution
shouldn't make any difference to us.
As Karen suggested its possible its something about the way you have
configured the printer driver.
Perhaps its set to always download the font rather than using
printer fonts?
The gif shouldn't do this from the size you quote and filled
rectangles shouldn't do it either.
A good experiment would be to eliminate each of these in turn to
see if it makes a massive difference.
But there are some things that can trigger text to be less efficient ..
are you using drawString or TextLayout.draw(..)?
If using the latter I'd urge you to try JDK 1.5 as that should help
a lot.
BTW I *HOPE* you are using either that or 1.4.2 already ..
-phil
Justin W wrote:
Hi Everyone,
I've created what I thought was going to be a relatively easy application
to send 5 page print jobs to printers throughout our company. I am
getting
extremely large spool files and it is causing serious performance
problems. Using a Windows 2000 server, printers are HP LaserJet 4100 and
4200 using PCL 6 drivers. Spool sizes on the 4100 are ~4MB and on the
4200
they are in excess of 12MB.
The pages contain mostly text, a small (3k) gif on one page, and some
various rectangles drawn on 3 of the 5 pages. Fonts are all Arial with
sizes from 7-12. It is a black and white document containing no alpha
that
I know of. I've tried writing the job to an offscreen image as specified
here:
http://java.sun.com/products/java-media/2D/forDevelopers/java2dfaq.html#spool
but the quality was very bad and the spool size was larger.
Any ideas?
Thanks in advance,
Justin
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-INTEREST.  For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message help.

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.

Re: [JAVA2D] Printing/Viewing report

[Phil Race]

Since it sounds like you have a data set which can be tablulated
- ie entered into a JTable then it *CAN* be as simple as
populate jtable and print it
JDK 1.5 now directly supports that.
See the 1.5 docs for javax.swing.JTable.print(..)
 I have dot matrix printer TVSE MSP 145.  old one!
Umm. So long as the windows drivers support it, it'll work
to some degree but it will have to work with the limited
resolution of that device.
-phil
miten mehta wrote:
Hello,
I have data records which I would like to extract and
print as neat report document.
can one tell me how I can create a document like say
ms word which distributes records on page and then let
me view/print pages.
I have dot matrix printer TVSE MSP 145.  old one!
I assume I cannot populate jtable and print it.  I
would need to handling priting in code.  For simple
reports I guess html will be better option as its easy
to generate markup compared to do drawing on canvas.
Miten.


__
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.