Re: [JAVA2D] ZWJ and ZWNJ

2006-07-24 Thread 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] How to do pixel based animation instead of MemoryImageSource?

2006-07-24 Thread Jim Graham

There are really 2 questions here:

- How do I manipulate a BufferedImage without interfering with its
ability to be accelerated under the covers?

- Is there a type of image that lives in hardware accelerated memory and
to which I can write directly to its pixels?

To answer the first question, first note that the type of hardware
acceleration provided by a BufferedImage is very limited.  It is what we
call a "managed image" which means that we can cache a copy of that
image in display memory if you copy it there frequently, but that copy
in the display memory is not where the pixels live - it is only a cached
copy.  To avoid interfering with this "managed image" mechanism, you
would currently have to use the relatively high level methods on
BufferedImage and Raster and these are not as fast as manipulating the
pixel array directly.  This concern doesn't really apply to your case,
though, since you modify all of the pixels in the image each time you
copy it to the screen and a managed image only provides benefit on the
second and subsequent times you render it to the screen.  (The first
time you render it to a screen or VolatileImage, the data must be
uploaded to the display card whether it is going directly to the
screen/VolatileImage or whether it is going to the cached copy.  Either
way, you still pay the performance penalty to get the pixels across the
bus to the card.)

The answer to the second question is that we currently have no image
type which has directly accessible pixels and which also lives in
accelerated memory - sort of an "uploadable texture" type of object.
That kind of image is on our wish list, but we have no schedule for
delivery of it yet...

   ...jim


This is my applet prototype:
=
public class Viewer extends Applet implements Runnable {
int[] idata = null;  // image pixel data array

Image view = null;  // viewport
int[] vdata = null;  // view data array

Image offImage = null;  // Offscreen rendering image

Graphics offGraphics  = null; // Offscreen rendering graphics context

int offwidth = 0; // Width of the offscreen graphics

int offheight = 0; // Height of the offscreen graphics

MemoryImageSource source = null;  // View is calcaulated here before dispaly

public Viewer() {
// use PixelGrabber to read pixels data into
// idata array
init();
}

public void init() {
// some init code
idata = readImagePixelData(imageFileName);
}

public void update(Graphics g) {
paint(g);
}

public void paint(Graphics g) {
// Setup offscreen rendering environmnent
offwidth  = getWidth();
offheight = getHeight();
offImage = createImage(offwidth, offheight);
offGraphics = offImage.getGraphics();

vdata = new int[vwidth * vheight];
source = new MemoryImageSource(vwidth, vheight, vdata, 0, vwidth);
source.setAnimated(true);
view = createImage(source);

// read pixel data from idata and
// use some warp transform to
// extract a new view according
// to user input
transform(idata, vdata, mouse_x, mouse_y);
source.newPixels();

offGraphics.drawImage(view, 0, 0, this);
g.drawImage(offImage, 0, 0, this);
}


===
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] ZWJ and ZWNJ

2006-07-24 Thread Peter B. West
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".