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
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?
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
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
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
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
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
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
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.
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
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
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,
[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,
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
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
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
[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
[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?
[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
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
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 =
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
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
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
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
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
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
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)
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
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
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
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
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
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
[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
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
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
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
[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
-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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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 :
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'
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
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
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
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
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
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
() 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
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
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
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.
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
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*
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
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.
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
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
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'
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
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
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
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().
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.
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 :
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
[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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 186 matches
Mail list logo
