Problem Java Printing in ECS 1.2R

I have a java app that works correctly in Warp 4 Fixpak 15. Under ECS 
1.2R there is a problem. Shapes such as a triangle filled by a series of 
adjoining lines do not come out correctly. The problem seems to be that 
whereas in Warp 4, printing resultion was given by dividing the screen 
width by something similar to the page width (and giving a typical 
result of 123), in 1.2R the print resolution seems to be always 72. What 
is worse, that 72 figure seems to define only the co-ordinate 
granularity not the line unit width. The line unit width looks as though 
it is the correct smaller value. This results in a series of supposedly 
adjoining lines having white space between.
The Java version is 1.1.8 and the ECS system was an upgrade from Warp 4. 
I can understand that the 72 value is 72 rather than some random value 
in that approximately 72 points to the inch is the standard printing 
measure. I also recall that some java documentation incorrectly states 
that printing resolution is 72 dpi. What I do not understand is why this 
inappropriate value is now surfacing in ECS. Can anyone explain why the 
print resolution has changed in ECS, and more importantly will the 
problem be fixed?
Regards

Peter J Seymour wrote:
> I have a java app that works correctly in Warp 4 Fixpak 15. Under ECS 
> 1.2R there is a problem. Shapes such as a triangle filled by a series of 
> adjoining lines do not come out correctly. The problem seems to be that 
> whereas in Warp 4, printing resultion was given by dividing the screen 
> width by something similar to the page width (and giving a typical 
> result of 123), in 1.2R the print resolution seems to be always 72. What 
> is worse, that 72 figure seems to define only the co-ordinate 
> granularity not the line unit width. The line unit width looks as though 
> it is the correct smaller value. This results in a series of supposedly 
> adjoining lines having white space between.
> The Java version is 1.1.8 and the ECS system was an upgrade from Warp 4. 
> I can understand that the 72 value is 72 rather than some random value 
> in that approximately 72 points to the inch is the standard printing 
> measure. I also recall that some java documentation incorrectly states 
> that printing resolution is 72 dpi. What I do not understand is why this 
> inappropriate value is now surfacing in ECS. Can anyone explain why the 
> print resolution has changed in ECS, and more importantly will the 
> problem be fixed?
> Regards
> Peter
I can follow this up with a bit more information.
I have run the same tests on my Warp 15 desktop and I get the expected 
print resolution (actually 127, not 123 as stated earlier). This 
improves the printing but does not completely cure the problem as there 
are still traces of whitespace showing in the filled area. It seems 
there are two separate issues: firstly the print resolution and secondly 
the unit line width.
I see what is happening as regards print resolution determining the 
spacing of the lines. Can any one explain how unit line width is 
determined? I wonder if it is influenced by printer capability but this 
would also have to affect the spool metafile since the effect also shows 
in the spool file viewer.
Any ideas?

Peter J Seymour wrote:
> I have a java app that works correctly in Warp 4 Fixpak 15. Under ECS 
> 1.2R there is a problem. Shapes such as a triangle filled by a series of 
> adjoining lines do not come out correctly. The problem seems to be that 
> whereas in Warp 4, printing resultion was given by dividing the screen 
> width by something similar to the page width (and giving a typical 
> result of 123), in 1.2R the print resolution seems to be always 72. What 
> is worse, that 72 figure seems to define only the co-ordinate 
> granularity not the line unit width. The line unit width looks as though 
> it is the correct smaller value. This results in a series of supposedly 
> adjoining lines having white space between.
> The Java version is 1.1.8 and the ECS system was an upgrade from Warp 4. 
> I can understand that the 72 value is 72 rather than some random value 
> in that approximately 72 points to the inch is the standard printing 
> measure. I also recall that some java documentation incorrectly states 
> that printing resolution is 72 dpi. What I do not understand is why this 
> inappropriate value is now surfacing in ECS. Can anyone explain why the 
> print resolution has changed in ECS, and more importantly will the 
> problem be fixed?
> Regards
> Peter
I seem to be on my own on this one.
The question of correctly filling a shape is easily dealt with. The 
situation is that a manual method used to work on certain 
software/hardware combinations but now does not work on certain other 
software/hardware combinations. Regardless of the rights and wrongs of 
the matter, the problem can be dealt with in java by using fillPolygon() 
operations rather than a manual technique. This should ensure that the 
shape is filled at device resolution.
There remains the problem that the "newly" imposed 72dpi resolution is

too coarse a granularity for the accurate sizing and placement of small 
items, whereas the former typical 129dpi was just about good enough.
Moving from Java 1.1.8 to 1.3.1 should resolve this issue as the latter 
has a simple way of setting the printer resolution. However, there is a 
consequence. As a matter of policy my java applications are deployed in 
native code. This requires a java to native compiler. Such is not 
available in OS/2 for java 1.3.1 (it is for java 1.1) and this means I 
will not be deploying any applications in OS/2 / ECS. Some might respond 
"big deal", but the situation is nevertheless a further erosion of
OS/2 
viability.
Regards