![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
[This entry is only likely to be of interest to Java programmers--and Java programmers that dink around with rendering details, at that. It's here to remind me of this issue later, and possibly to help someone out that happens to land here via a search on the problem's identifying characteristics.]
The fundamental BasicStroke constructor requires the user to define several quantities, including something called 'miterlimit'; this is only used if the 'join' parameter is set to JOIN_MITER. The API documentation states that 'miterlimit' must be >= 1.0f. However, if you set this parameter to 0f, it renders just fine...until you use EPSDump to dump the drawing area to a file. Apparently the PostScript interpreter is more strict about the setting of this value, even when it's not used; if the value is < 1.0f, the EPS file generated is both incomplete (not everything is rendered) and corrupt (Mac OS X's Preview can't open it).
The resolution is simple: follow the documentation, and specify a value >= 1.0f for 'miterlimit' regardless of your join type. But it sure would be nice if Java would throw an IllegalArgumentException in this case. (It would have saved me an hour+ of debugging.)
The fundamental BasicStroke constructor requires the user to define several quantities, including something called 'miterlimit'; this is only used if the 'join' parameter is set to JOIN_MITER. The API documentation states that 'miterlimit' must be >= 1.0f. However, if you set this parameter to 0f, it renders just fine...until you use EPSDump to dump the drawing area to a file. Apparently the PostScript interpreter is more strict about the setting of this value, even when it's not used; if the value is < 1.0f, the EPS file generated is both incomplete (not everything is rendered) and corrupt (Mac OS X's Preview can't open it).
The resolution is simple: follow the documentation, and specify a value >= 1.0f for 'miterlimit' regardless of your join type. But it sure would be nice if Java would throw an IllegalArgumentException in this case. (It would have saved me an hour+ of debugging.)