From Dmitri.Trembovetski at Sun.COM Sat Jan 5 00:16:27 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 04 Jan 2008 16:16:27 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above In-Reply-To: <4769B004.10308@Sun.COM> References: <1197121416.14405.50.camel@dylan> <4769B004.10308@Sun.COM> Message-ID: <477ECC5B.6050703@Sun.COM> Hi Dan, did you receive a confirmation about the SCA? Thanks, Dmitri Dmitri Trembovetski wrote: > > Hi Dan, > > I know that you sent your SCA (repeatedly =) so > I looked at the fix. > > It looks good. > > Please see my comments below. > > Dan Munckton wrote: >> APPROACH >> >> The fix is really simple it just checks to make sure RANDR's version is >> 1.2 or greater if usingXinerama is true, if this is all fine it proceeds >> to load the libXrandr funcs. > > Sounds good. > >> For the moment I've completely ignored 6599351, and not touched any of >> the Xinerama loading code at all. > > OK, I think it's a good idea to separate the two fixes. > >> BTW I note that with 6599351 the user has an old style X dual-head >> config without using Xinerama - I found a note on the Debian Xrandr1.2 >> Howto wiki page [1] explaining that this configuration should crash >> Xserver 1.3. Does it behave differently in Solaris X? > > You mean, if randr is present? > It could be that it didn't have randr extension. > It looks from the comments in the bug report that 1.3 works > fine with dual screens w/o xinerama in general. > >> TESTING >> >> The equipment I have here will allow me to test single monitor setups >> with X servers 1.2 and 1.3. Java now behaves as expected in the >> following cases: >> >> 1) Xserver 1.2 + 1 monitor + Xrandr >> Expect: isFullScreenSupported: true >> Result: PASS >> >> 2) Xserver 1.2 + 1 monitor + Xinerama enabled (Xinerama won't actually >> load but Xrandr and DRI won't load either) >> Expect: isFullScreenSupported: false >> Result: PASS >> >> 3) Xserver 1.3 + 1 monitor + Xrandr + fake Xinerama >> Expect: isFullScreenSupported: true >> Result: PASS >> >> 4) Xserver 1.3 + 1 monitor + Xinerama enabled (Xinerama won't actually >> load but Xrandr and DRI won't load either) >> Expect: isFullScreenSupported: false >> Result: PASS > > I assume this is all on linux, right? > >> TESTING TODO >> >> I have an external LCD monitor at work which I can hook up to my laptop >> next week. This should allow me to test out Xrandr 1.2 multi-monitor >> setups. I'll post results as soon as complete. >> >> However I don't think I can test out Xinerama dual head configs. I tried >> to set this up once before but failed - I'm still not 100% certain if >> Xinerama is actually compiled into my X server I will need to check this >> out properly. >> If anyone here has a multi monitor setup already and would be prepared >> to help me test the following scenarios I'd be very grateful. >> >> 5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load) >> Expect: isFullScreenSupported: false >> >> 6) Xserver 1.3 + 2 monitors + Xinerama >> Expect: isFullScreenSupported: false > > Ugh. That might be a problem - we don't have too many > multiscreen solaris or linux systems that we could install > new X server on. But we'll see what we can do. > > We can at least test on the configuration we have. > I have a Solaris 10 machine with dual (non-xinerama) > screen - the fs mode isn't supported on it. > >> I am also still to run the jtreg tests against this. I will come back >> with results. > > I can't think of a good automated regression test for this fix. > You can I suppose write a jtreg regression test as script > (it is allowed), run xdpyinfo and find out that randr of the > correct version is installed and then test if fullscreen > is supported but it may not necessarily be a fully correct test - > fullscreen may not be enabled for other reasons. > >> Also, do I need to mail both awt-dev and 2d-dev or will just one do in >> future? > > This particular fix is 2D only, so we can continue on 2d-dev. > The other one - we'll see. I suppose it's not that much of a problem > if you cc both lists. > > Thanks, > Dmitri > > >> >> Cheers >> >> Dan >> >> >> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469 >> [1] Section VI.3 of http://wiki.debian.org/XStrikeForce/HowToRandR12 >> From Dmitri.Trembovetski at Sun.COM Sat Jan 5 00:26:06 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 04 Jan 2008 16:26:06 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above In-Reply-To: <477ECC5B.6050703@Sun.COM> References: <1197121416.14405.50.camel@dylan> <4769B004.10308@Sun.COM> <477ECC5B.6050703@Sun.COM> Message-ID: <477ECE9E.7020106@Sun.COM> OK, Phil actually bothered to check, and now we see your name in the list of SCA signatories! Woo-hoo! Thanks, Dmitri Dmitri Trembovetski wrote: > > Hi Dan, > > did you receive a confirmation about the SCA? > > Thanks, > Dmitri > > > Dmitri Trembovetski wrote: >> >> Hi Dan, >> >> I know that you sent your SCA (repeatedly =) so >> I looked at the fix. >> >> It looks good. >> >> Please see my comments below. >> >> Dan Munckton wrote: >>> APPROACH >>> >>> The fix is really simple it just checks to make sure RANDR's version is >>> 1.2 or greater if usingXinerama is true, if this is all fine it proceeds >>> to load the libXrandr funcs. >> >> Sounds good. >> >>> For the moment I've completely ignored 6599351, and not touched any of >>> the Xinerama loading code at all. >> >> OK, I think it's a good idea to separate the two fixes. >> >>> BTW I note that with 6599351 the user has an old style X dual-head >>> config without using Xinerama - I found a note on the Debian Xrandr1.2 >>> Howto wiki page [1] explaining that this configuration should crash >>> Xserver 1.3. Does it behave differently in Solaris X? >> >> You mean, if randr is present? >> It could be that it didn't have randr extension. >> It looks from the comments in the bug report that 1.3 works >> fine with dual screens w/o xinerama in general. >> >>> TESTING >>> >>> The equipment I have here will allow me to test single monitor setups >>> with X servers 1.2 and 1.3. Java now behaves as expected in the >>> following cases: >>> >>> 1) Xserver 1.2 + 1 monitor + Xrandr >>> Expect: isFullScreenSupported: true >>> Result: PASS >>> >>> 2) Xserver 1.2 + 1 monitor + Xinerama enabled (Xinerama won't actually >>> load but Xrandr and DRI won't load either) >>> Expect: isFullScreenSupported: false >>> Result: PASS >>> >>> 3) Xserver 1.3 + 1 monitor + Xrandr + fake Xinerama >>> Expect: isFullScreenSupported: true >>> Result: PASS >>> >>> 4) Xserver 1.3 + 1 monitor + Xinerama enabled (Xinerama won't actually >>> load but Xrandr and DRI won't load either) >>> Expect: isFullScreenSupported: false >>> Result: PASS >> >> I assume this is all on linux, right? >> >>> TESTING TODO >>> >>> I have an external LCD monitor at work which I can hook up to my laptop >>> next week. This should allow me to test out Xrandr 1.2 multi-monitor >>> setups. I'll post results as soon as complete. >>> >>> However I don't think I can test out Xinerama dual head configs. I tried >>> to set this up once before but failed - I'm still not 100% certain if >>> Xinerama is actually compiled into my X server I will need to check this >>> out properly. >>> If anyone here has a multi monitor setup already and would be prepared >>> to help me test the following scenarios I'd be very grateful. >>> >>> 5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load) >>> Expect: isFullScreenSupported: false >>> >>> 6) Xserver 1.3 + 2 monitors + Xinerama >>> Expect: isFullScreenSupported: false >> >> Ugh. That might be a problem - we don't have too many >> multiscreen solaris or linux systems that we could install >> new X server on. But we'll see what we can do. >> >> We can at least test on the configuration we have. >> I have a Solaris 10 machine with dual (non-xinerama) >> screen - the fs mode isn't supported on it. >> >>> I am also still to run the jtreg tests against this. I will come back >>> with results. >> >> I can't think of a good automated regression test for this fix. >> You can I suppose write a jtreg regression test as script >> (it is allowed), run xdpyinfo and find out that randr of the >> correct version is installed and then test if fullscreen >> is supported but it may not necessarily be a fully correct test - >> fullscreen may not be enabled for other reasons. >> >>> Also, do I need to mail both awt-dev and 2d-dev or will just one do in >>> future? >> >> This particular fix is 2D only, so we can continue on 2d-dev. >> The other one - we'll see. I suppose it's not that much of a problem >> if you cc both lists. >> >> Thanks, >> Dmitri >> >> >>> >>> Cheers >>> >>> Dan >>> >>> >>> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469 >>> [1] Section VI.3 of http://wiki.debian.org/XStrikeForce/HowToRandR12 >>> From Ben.LOUD at baesystems.com Mon Jan 14 13:39:45 2008 From: Ben.LOUD at baesystems.com (LOUD, Ben) Date: Tue, 15 Jan 2008 00:09:45 +1030 Subject: [OpenJDK 2D-Dev] 4189647 - Dimension2D.Float/.Double Message-ID: <755F5FA20B29364FBA287DB1BEBCE80A012CAF74@SBEMAIL1.au.baesystems.com> I was just wondering, is there any reason why there are no Float and Double subclasses of Dimension2D? I'm suprised such a simple thing was never included. Thats all. Thanks! "Warning: The information contained in this email and any attached files is confidential to BAE Systems Australia. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is expressly prohibited. If you have received this email in error, please notify us immediately. VIRUS: Every care has been taken to ensure this email and its attachments are virus free, however, any loss or damage incurred in using this email is not the sender's responsibility. It is your responsibility to ensure virus checks are completed before installing any data sent in this email to your computer." -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jim.A.Graham at Sun.COM Mon Jan 14 20:07:50 2008 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Mon, 14 Jan 2008 12:07:50 -0800 Subject: [OpenJDK 2D-Dev] 4189647 - Dimension2D.Float/.Double In-Reply-To: <755F5FA20B29364FBA287DB1BEBCE80A012CAF74@SBEMAIL1.au.baesystems.com> References: <755F5FA20B29364FBA287DB1BEBCE80A012CAF74@SBEMAIL1.au.baesystems.com> Message-ID: <0JUN00BM7H6O1OE0@fe-sfbay-09.sun.com> Hi Ben, Since it was only used for doing component layouts (in integer space), it wasn't really needed anywhere, though I suppose that this begs the question as to why Dimension2D was created in the first place. (scratches head, doesn't remember). Do you have a use case for it now? ...jim LOUD, Ben wrote: > I was just wondering, is there any reason why there are no Float and Double subclasses of Dimension2D? I'm suprised such a simple thing was never included. > > Thats all. Thanks! > > > "Warning: > The information contained in this email and any attached files is > confidential to BAE Systems Australia. If you are not the intended > recipient, any use, disclosure or copying of this email or any > attachments is expressly prohibited. If you have received this email > in error, please notify us immediately. VIRUS: Every care has been > taken to ensure this email and its attachments are virus free, > however, any loss or damage incurred in using this email is not the > sender's responsibility. It is your responsibility to ensure virus > checks are completed before installing any data sent in this email to > your computer." > > From Ben.LOUD at baesystems.com Tue Jan 15 00:27:46 2008 From: Ben.LOUD at baesystems.com (LOUD, Ben) Date: Tue, 15 Jan 2008 10:57:46 +1030 Subject: [OpenJDK 2D-Dev] 4189647 - Dimension2D.Float/.Double In-Reply-To: <0JUN00BM7H6O1OE0@fe-sfbay-09.sun.com> References: <755F5FA20B29364FBA287DB1BEBCE80A012CAF74@SBEMAIL1.au.baesystems.com> <0JUN00BM7H6O1OE0@fe-sfbay-09.sun.com> Message-ID: <755F5FA20B29364FBA287DB1BEBCE80A037C3216@SBEMAIL1.au.baesystems.com> Yeah, it would come in handy just for general purpose use. I was planning an API where I simply needed to return a width and height in double precision, and obviously would prefer to use standard classes. In this case, it was for layout of graphic elements, but in user space, and I needed to stay resolution independent (for printing). Essentially I had the equivelant of AWT's getPreferredSize(). Not a showstopper, but I thought they might be worthy of inclusion, even for the sake of completeness. -----Original Message----- From: Jim.A.Graham at sun.com [mailto:Jim.A.Graham at sun.com] Sent: Tuesday, 15 January 2008 6:38 AM To: LOUD, Ben Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] 4189647 - Dimension2D.Float/.Double Hi Ben, Since it was only used for doing component layouts (in integer space), it wasn't really needed anywhere, though I suppose that this begs the question as to why Dimension2D was created in the first place. (scratches head, doesn't remember). Do you have a use case for it now? ...jim LOUD, Ben wrote: > I was just wondering, is there any reason why there are no Float and Double subclasses of Dimension2D? I'm suprised such a simple thing was never included. > > Thats all. Thanks! > > > "Warning: > The information contained in this email and any attached files is > confidential to BAE Systems Australia. If you are not the intended > recipient, any use, disclosure or copying of this email or any > attachments is expressly prohibited. If you have received this email > in error, please notify us immediately. VIRUS: Every care has been > taken to ensure this email and its attachments are virus free, > however, any loss or damage incurred in using this email is not the > sender's responsibility. It is your responsibility to ensure virus > checks are completed before installing any data sent in this email to > your computer." > > "Warning: The information contained in this email and any attached files is confidential to BAE Systems Australia. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is expressly prohibited. If you have received this email in error, please notify us immediately. VIRUS: Every care has been taken to ensure this email and its attachments are virus free, however, any loss or damage incurred in using this email is not the sender's responsibility. It is your responsibility to ensure virus checks are completed before installing any data sent in this email to your computer." From lists at munckfish.net Wed Jan 16 15:37:39 2008 From: lists at munckfish.net (Dan Munckton) Date: Wed, 16 Jan 2008 15:37:39 +0000 Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above In-Reply-To: <1197369278.7494.8.camel@dylan> References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com> <1197369278.7494.8.camel@dylan> Message-ID: <1200497859.7514.14.camel@dylan> Hi all Happy new year. Although I've been silent for a bit, I'm still working on this. I've tested more widely now and have managed to configure multi-monitor setups on both Xorg server's 1.2 and 1.3. I'm also now on the SCA contributors list. UPDATED PATCH Please see the attached updated patch. I needed to add code to prevent FSEM (Fullscreen Exclusive Mode) on Xorg 1.3 with 2 or more monitors. Although I suspect this is technically possible now (as it is in Windows) running a full-screen app in a multi-monitor setup currently disables all Graphics devices except the default and requires an X restart to bring them back. So I guess it'll need more work to support that. Should I raise an RFE? Is this something worth doing? FEEDBACK SO FAR Guys, am I on the right lines? Yuri, you were going to work on 6599351, does what I've done fit in or were you planning more radical changes? ADVICE ON JTREG APPROACH Also I need some advice on how to approach a jtreg test for this. My current plan is to use a shell script to query command line tools like xdpyinfo and xrandr and then run a Java tool to check whether FSEM is or isn't supported as expected. But I've no idea (yet) how portable this would be across platforms and across versions of X. I notice there aren't a great deal FSEM related tests in the source other than one in jdk/test/java/awt/Fullscreen (which incidentally appears to be missing a source file 'DisplayModeChanger.java'). I can see the benefit in providing a regression test for this but I'm concerned that it's very dependent on the environment the tests are being run on as to whether it'll get spotted at all. Do you guys think it's a good idea to make a test for this or is it more likely to be a pest to maintain? Thanks Dan Munckton -------------- next part -------------- A non-text attachment was scrubbed... Name: 6636469_v2.diff Type: text/x-patch Size: 3709 bytes Desc: not available URL: From lists at munckfish.net Thu Jan 17 18:10:10 2008 From: lists at munckfish.net (Dan Munckton) Date: Thu, 17 Jan 2008 18:10:10 +0000 Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above In-Reply-To: <1200497859.7514.14.camel@dylan> References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com> <1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan> Message-ID: <1200593410.6546.2.camel@dylan> Hi Please disregard all of my previous patches. I've just fixed a logic error I made when checking the RANDR version. Now fixed, patch v3 attached. Thanks Dan Munckton -------------- next part -------------- A non-text attachment was scrubbed... Name: 6636469_v3.diff Type: text/x-patch Size: 3738 bytes Desc: not available URL: From Dmitri.Trembovetski at Sun.COM Thu Jan 17 18:40:00 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 17 Jan 2008 10:40:00 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above In-Reply-To: <1200593410.6546.2.camel@dylan> References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com> <1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan> <1200593410.6546.2.camel@dylan> Message-ID: <478FA100.7070401@Sun.COM> Hi Dan, the patch looks fine. The only thing is that we typically try to avoid the use of goto if possible (like in this case since you don't win much by using it), so I'd suggest to just use + dlclose(pLibRandR); + return JNI_FALSE; instead of + goto return_false; Disabling fullscreen for multiscreen systems is ok with me. I agree that it'll be hard to create a robust automated test for this bug (and there's plenty of manual tests already, adding a new one won't be of much benefit), so I suggest we skip on regression test for this one. Regarding testing configurations: I have requested a sparc system with Nevada (so that it has the new X server), and also an x86/64 machine for linux/solaris. Once we have those set up we can proceed with the integration. Thanks, Dmitri Dan Munckton wrote: > Hi > > Please disregard all of my previous patches. I've just fixed a logic > error I made when checking the RANDR version. Now fixed, patch v3 > attached. > > Thanks > > Dan Munckton > From lists at munckfish.net Fri Jan 18 13:26:00 2008 From: lists at munckfish.net (Dan Munckton) Date: Fri, 18 Jan 2008 13:26:00 +0000 Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above In-Reply-To: <4769B004.10308@Sun.COM> References: <1197121416.14405.50.camel@dylan> <4769B004.10308@Sun.COM> Message-ID: <1200662760.6148.43.camel@dylan> Hi Dmitri Apologies. I've only just seen this mail - I setup a spam filter before Xmas but it was too keen. I've just rescued this mail (and 3 others you sent late 07) from my Junk folder. Grrr. Spam filter switched to OFF now :) > I know that you sent your SCA (repeatedly =) so > I looked at the fix. > > It looks good. Excellent thanks. What a relief! > > BTW I note that with 6599351 the user has an old style X dual-head > > config without using Xinerama - I found a note on the Debian Xrandr1.2 > > Howto wiki page [1] explaining that this configuration should crash > > Xserver 1.3. Does it behave differently in Solaris X? > > You mean, if randr is present? Yes. > It could be that it didn't have randr extension. > It looks from the comments in the bug report that 1.3 works > fine with dual screens w/o xinerama in general. Ok maybe I misinterpreted the comments. I thought that although the guy said he wasn't explicitly using Xinerama (ie not positively enabled in xorg.conf) that it was in fact still enabled because of the new RANDR 1.2 backend. Anyway I'm still not sure I can recreate that issue with the gear I have here. > > > TESTING > > > > I assume this is all on linux, right? Yes. I'm currently running Ubuntu 7.04 (Feisty) which has Xorg server 1.2. To test with Xorg server 1.3 I've been using the bootable CD-ROM of Ubuntu 7.10 (Gutsy). I'm using a laptop with ATI RADEON X700. The laptop monitor is a 1440x900 LCD panel. It has an extra VGA out which I'm connecting to a 19" LCD external monitor. > > > TESTING TODO > > If anyone here has a multi monitor setup already and would be prepared > > to help me test the following scenarios I'd be very grateful. > > > > 5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load) > > Expect: isFullScreenSupported: false > > > > 6) Xserver 1.3 + 2 monitors + Xinerama > > Expect: isFullScreenSupported: false > > Ugh. That might be a problem - we don't have too many > multiscreen solaris or linux systems that we could install > new X server on. But we'll see what we can do. > > We can at least test on the configuration we have. > I have a Solaris 10 machine with dual (non-xinerama) > screen - the fs mode isn't supported on it. > In fact I have now been able to test cases 5 & 6 above. Is your Solaris machine using what people refer to as the "old style dual-head" configuration enabled with Option "DualHead" "true" in xorg.conf? If so this is something I haven't been able to setup here. But it's interesting you can't use FSEM as I would have presumed this possible as long as Xinerama isn't actually in use. Cheers Dan From lists at munckfish.net Fri Jan 18 14:10:23 2008 From: lists at munckfish.net (Dan Munckton) Date: Fri, 18 Jan 2008 14:10:23 +0000 Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above In-Reply-To: <478FA100.7070401@Sun.COM> References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com> <1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan> <1200593410.6546.2.camel@dylan> <478FA100.7070401@Sun.COM> Message-ID: <1200665423.6148.77.camel@dylan> Hi New patch attached with updates as requested. Note that I have also moved the logic which ensures single screen only configs within the "if (usingXinerama)" block below the RANDR version check. I just feel this is tidier it means that the code path for users of Xorg server 1.2 and below is exactly as before, and the patch then only adds support for users of Xorg 1.3 and above and no more. > > I agree that it'll be hard to create a robust automated > test for this bug (and there's plenty of manual tests > already, adding a new one won't be of much benefit), > so I suggest we skip on regression test for this one. Ok fine. One important thing I'd like to bring to your attention is this: so far I've been testing FSEM mode using my employer's own fullscreen product [0] and it's been working fine. Today I decided to check using the DisplayModeTest example from the Java Fullscreen Exclusive Mode Tutorial [1]. With this app on Xorg 1.3/RANDR 1.2, the mouse cursor is lost after changing display mode. Sometimes it pops back after a short time, other times I have to Alt+Tab out and back in to get it back. So far I've tried explicitly resetting the cursor (this.setCursor(Cursor.getDefaultCursor()) and adding an extra sync (Toolkit.getDefaultToolkit().sync()) when the mode changes but neither of these helped any. I'll see if I can find out more, but would welcome any suggestions as to why this may be. Is there a schedule available on the planned dates of Java 6 updates or OpenJDK promotions/builds? I'm sure someone else asked this question and was directed to the mail archives but I couldn't find a mail with the details. Cheers Dan [0] http://www.inquizitor.com/ [1] http://java.sun.com/docs/books/tutorial/extra/fullscreen/example-1dot4/DisplayModeTest.java -------------- next part -------------- A non-text attachment was scrubbed... Name: 6636469_v4.diff Type: text/x-patch Size: 3344 bytes Desc: not available URL: From msp at altlinux.ru Wed Jan 23 14:35:47 2008 From: msp at altlinux.ru (Michael Pozhidaev) Date: Wed, 23 Jan 2008 20:35:47 +0600 Subject: [OpenJDK 2D-Dev] PostScript generation Message-ID: Hello, everybody! It is my first post to this list. Sorry, if I have chosen the list incorrectly. I don't want to be disturbing. Please, point me to the another one, if there is the better place to discuss this problem. The problem, I can not solve, is in postscript generator in Java. I am using java (both 1.4.2 and 1.6) in Russian GNU/Linux distribution - AltLinux. On my machine CUPS 1.2.10 is installed and I have HP LaserJet 1000 connected and configured. My Java prints, generated with jasperreports, are placed incorrectly on the page, moved up on 2-3cm and exceed the page border. When I ask Java to save ps output to the file, this file can be viewed with gs or evince. Direct call of gs with command line produces correct image, but in evince there is the same problem as in printing. All other applications on my machine make their prints perfectly without any problems. My friend tried to make prints in the same system, but with another HP laser printer, and he got a completely wrong page, just with two letters "IB" on it. I think, is CUPS providing to Java any information about the installed printer (anything like PPPD file)? Maybe this information is wrong for my printer or Java is not able to process it correctly? I can sent to anybody the ps files I have received with Java and which can not be printed correctly. Please, help me to solve this problem.! Thanks! :) -- With best wishes. Michael Pozhidaev. Tomsk State University. Computer science department. From Jennifer.Godinez at Sun.COM Wed Jan 23 18:43:32 2008 From: Jennifer.Godinez at Sun.COM (Jennifer Godinez) Date: Wed, 23 Jan 2008 10:43:32 -0800 Subject: [OpenJDK 2D-Dev] PostScript generation In-Reply-To: References: Message-ID: <47978AD4.8060804@Sun.COM> Hi Michael, You mentioned you are using JasperReports. Do you use jasperreports API? Can you send a code snippet? jennifer Michael Pozhidaev wrote: > Hello, everybody! > It is my first post to this list. Sorry, if I have chosen the list incorrectly. > I don't want to be disturbing. Please, point me to the another one, if there is the better place to discuss this problem. > The problem, I can not solve, is in postscript generator in Java. > I am using java (both 1.4.2 and 1.6) in Russian GNU/Linux distribution - AltLinux. > On my machine CUPS 1.2.10 is installed and I have HP LaserJet 1000 connected and configured. > My Java prints, generated with jasperreports, are placed incorrectly on the page, > moved up on 2-3cm and exceed the page border. > When I ask Java to save ps output to the file, this file can be > viewed with gs or evince. Direct call of gs with command line produces correct image, > but in evince there is the same problem as in printing. > All other applications on my machine make their prints perfectly without > any problems. My friend tried to make prints in the same system, but > with another HP laser printer, and he got a completely wrong page, just with two letters "IB" on it. > I think, is CUPS providing to Java any information about the installed printer (anything like PPPD file)? > Maybe this information is wrong for my printer or Java is not able to process it correctly? > I can sent to anybody the ps files I have received with Java and which > can not be printed correctly. > Please, help me to solve this problem.! Thanks! :) From Phil.Race at Sun.COM Wed Jan 23 18:47:10 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 23 Jan 2008 10:47:10 -0800 Subject: [OpenJDK 2D-Dev] PostScript generation In-Reply-To: <47978AD4.8060804@Sun.COM> References: <47978AD4.8060804@Sun.COM> Message-ID: <47978BAE.8040809@sun.com> This is not the right alias for usage questions. Please re-direct to either : JAVA2D-INTEREST at JAVA.SUN.COM to which you can subscribe to that list using listserv at JAVA.SUN.COM, Or you can post in the Java2D forum at http://forums.java.net/jive/forum.jspa?forumID=69&start=0 -phil. Jennifer Godinez wrote: > Hi Michael, > > You mentioned you are using JasperReports. Do you use jasperreports > API? Can you send a code snippet? > > jennifer > > Michael Pozhidaev wrote: >> Hello, everybody! >> It is my first post to this list. Sorry, if I have chosen the list >> incorrectly. >> I don't want to be disturbing. Please, point me to the another one, if >> there is the better place to discuss this problem. >> The problem, I can not solve, is in postscript generator in Java. >> I am using java (both 1.4.2 and 1.6) in Russian GNU/Linux distribution >> - AltLinux. >> On my machine CUPS 1.2.10 is installed and I have HP LaserJet 1000 >> connected and configured. >> My Java prints, generated with jasperreports, are placed incorrectly >> on the page, moved up on 2-3cm and exceed the page border. >> When I ask Java to save ps output to the file, this file can be viewed >> with gs or evince. Direct call of gs with command line produces >> correct image, >> but in evince there is the same problem as in printing. >> All other applications on my machine make their prints perfectly >> without any problems. My friend tried to make prints in the same >> system, but with another HP laser printer, and he got a completely >> wrong page, just with two letters "IB" on it. >> I think, is CUPS providing to Java any information about the installed >> printer (anything like PPPD file)? >> Maybe this information is wrong for my printer or Java is not able to >> process it correctly? >> I can sent to anybody the ps files I have received with Java and which >> can not be printed correctly. >> Please, help me to solve this problem.! Thanks! :)