Thread: [Tuxpaint-devel] [fwd] tuxpaint print bug on Brother HL 2700 CN
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
tuxpaint-devel
|
From: Bill K. <nb...@so...> - 2006-08-17 21:59:42
|
My friend Micah wrote in: Thought you might want to know about this bug. It's been reported for Ubuntu and Debian: https://launchpad.net/distros/ubuntu/+source/tuxpaint/+bug/49079 My guess would be that it's because BoundingBox isn't specified, which violates your claim to conform to the Adobe document guidelines (via the %!Adobe-PS-3.0 ... comment). Albert, I believe you did the PostScript stuff in Tux Paint. Care to comment? Micah's patch (attached to that bug) simply has TP spit out plain PS, but suggests that fixing the EPSF stuff would be a more appropriate fix. I also wonder if this is the cause of trouble that Mac OS X users have been having with printing in the latest Tux Paint ... ? Thanks, -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Albert C. <aca...@gm...> - 2006-08-18 04:28:30
|
On 8/17/06, Bill Kendrick <nb...@so...> wrote: > > My friend Micah wrote in: > > Thought you might want to know about this bug. > It's been reported for Ubuntu and Debian: > > https://launchpad.net/distros/ubuntu/+source/tuxpaint/+bug/49079 > > My guess would be that it's because BoundingBox isn't specified, which > violates your claim to conform to the Adobe document guidelines (via > the %!Adobe-PS-3.0 ... comment). > > > Albert, I believe you did the PostScript stuff in Tux Paint. > Care to comment? Micah's patch (attached to that bug) simply has TP spit > out plain PS, but suggests that fixing the EPSF stuff would be a more > appropriate fix. I did write it. It's been a while. Note that there is no evidence that the patch works. So far, it's just a random idea to try. Defining a bounding box might be impossible. The code scales the image automatically so that Tux Paint doesn't need to care about paper sizes. The alternative is to make paper size part of the locale. > I also wonder if this is the cause of trouble that Mac OS X users have > been having with printing in the latest Tux Paint ... ? Doesn't that use some Cocoa API instead? |
|
From: Micah J. C. <mi...@co...> - 2006-08-18 08:23:52
|
On Fri, Aug 18, 2006 at 12:28:27AM -0400, Albert Cahalan wrote: > On 8/17/06, Bill Kendrick <nb...@so...> wrote: > > > > Albert, I believe you did the PostScript stuff in Tux Paint. > > Care to comment? Micah's patch (attached to that bug) simply has TP spit > > out plain PS, but suggests that fixing the EPSF stuff would be a more > > appropriate fix. > > I did write it. It's been a while. > > Note that there is no evidence that the patch works. > So far, it's just a random idea to try. Right. I want to go for the low-hanging fruit to see what the easiest fix is that could cause it to start working for this user, before moving onto more difficult challenges (such as trying to get BB working). AFAIK, for a single-page document such as this, with no fancy resource management, there's probably no real need to follow the Adobe DSC. But somehow it can make the code it look nicer. :-) I was wondering, though, why you chose to output it as an EPS... was there thought down the road for generating files from this code? > Defining a bounding box might be impossible. The code > scales the image automatically so that Tux Paint doesn't > need to care about paper sizes. The alternative is to make > paper size part of the locale. > > > I also wonder if this is the cause of trouble that Mac OS X users have > > been having with printing in the latest Tux Paint ... ? > > Doesn't that use some Cocoa API instead? Yeah, I wouldn't think they're related. AIUI, Mac graphics are defined in terms of PDF file operations anyway: you just "draw" it to some context, and Mac OS handles the printing. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ |
|
From: Albert C. <aca...@gm...> - 2006-08-19 00:13:57
|
On 8/18/06, Micah J. Cowan <mi...@co...> wrote: > On Fri, Aug 18, 2006 at 12:28:27AM -0400, Albert Cahalan wrote: > Right. I want to go for the low-hanging fruit to see what the easiest > fix is that could cause it to start working for this user, before moving > onto more difficult challenges (such as trying to get BB working). > > AFAIK, for a single-page document such as this, with no fancy resource > management, there's probably no real need to follow the Adobe DSC. But > somehow it can make the code it look nicer. :-) > > I was wondering, though, why you chose to output it as an EPS... was > there thought down the road for generating files from this code? There is a certain level I need to allow RGB output, and a certain level needed for an unimplemented sRGB-to-AdobeRGB transform. As I recall, that level requires or strongly suggests the other stuff. All too often I have encountered postscript files that don't work nicely in postscript viewers. It's nice to support all the extras needed for things to work well. I did that as best I could. I don't see a reason to be shipping EPS files around, but it is important that things work nicely for printers that may require the newer comments. It is extremely unfortunate that Tux Paint can't get any decent feedback from the printer. There is no reliable way to show the user how things will look on the page. We can't even tell what shape the paper is. |
|
From: Micah J. C. <mi...@co...> - 2006-08-19 01:40:32
|
On Fri, Aug 18, 2006 at 08:13:50PM -0400, Albert Cahalan wrote: > On 8/18/06, Micah J. Cowan <mi...@co...> wrote: > > On Fri, Aug 18, 2006 at 12:28:27AM -0400, Albert Cahalan wrote: > > > Right. I want to go for the low-hanging fruit to see what the easiest > > fix is that could cause it to start working for this user, before moving > > onto more difficult challenges (such as trying to get BB working). > > > > AFAIK, for a single-page document such as this, with no fancy resource > > management, there's probably no real need to follow the Adobe DSC. But > > somehow it can make the code it look nicer. :-) > > > > I was wondering, though, why you chose to output it as an EPS... was > > there thought down the road for generating files from this code? > > There is a certain level I need to allow RGB output, and a certain > level needed for an unimplemented sRGB-to-AdobeRGB transform. > > As I recall, that level requires or strongly suggests the other stuff. > > All too often I have encountered postscript files that don't work > nicely in postscript viewers. It's nice to support all the extras > needed for things to work well. I did that as best I could. I don't > see a reason to be shipping EPS files around, but it is important > that things work nicely for printers that may require the newer > comments. Oh... actually, the DSC comment stuff isn't supposed to be required, and is a separate specification from PostScript. And, you can do it without making it an EPS file (you just drop the stuff after %!PS-Adobe-3.0). Mostly, DSC is for caching stuff, so the printer doesn't waste time/memory doing things more often than it has to. ...After doing some reading, AFAICT I was wrong about BoundingBox being required: it would seem that this is probably not the cause of problems on the user's printer. What I think /might/ cause problems, is the fact that the %%BeginData section includes a line with the word "image" on it, but doesn't include those 6 bytes (including newline) in the specified byte count. I wonder if moving that line before the %%BeginData section just might improve things. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ |
|
From: Micah J. C. <mi...@co...> - 2006-08-23 17:27:10
|
(Replying to myself) On Fri, Aug 18, 2006 at 06:40:29PM -0700, Micah J. Cowan wrote: > ...After doing some reading, AFAICT I was wrong about BoundingBox being > required: it would seem that this is probably not the cause of problems > on the user's printer. As it turns out, I was only /partially/ wrong about BoundingBox being required. It is in fact required if the document is an EPS. If we remove the EPSF bit from the first line, then it's not required. The extra six bytes for "image\n" is also a potential trouble spot, as we already discussed. And, in reading over parts of the PSRM again, I also found that it is highly recommended to include the line "%%EndProlog" in your document, even if you don't put anything in your prolog section. Actually, although the description of %%Begin(End)Prolog says you "should" include the line, section 4 says that conforming documents "must" include it (and, to be kosher, we should probably include the %%BeginProlog as well). I've posted a tarball to the Ubuntu bug description at https://launchpad.net/distros/ubuntu/+source/tuxpaint/+bug/49079 with various test files for the user to attempt printing. It includes the original, the original stripped of DSC comments, the original minus the EPSF stuff, and the original, minus the EPSF stuff and with an adjusted byte-count to include the "image\n". (I didn't consider the prolog stuff until after I'd posted the tarball.) Hopefully the user will test this out and give us some much-needed data; regardless, though, I think addressing the three areas of trouble above should probably improve the portability of tuxpaint's output. Thanks for taking the time to look into this, Albert. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ |
|
From: Albert C. <aca...@gm...> - 2006-08-19 02:32:56
|
> What I think /might/ cause problems, is the fact that the %%BeginData > section includes a line with the word "image" on it, but doesn't include > those 6 bytes (including newline) in the specified byte count. I wonder > if moving that line before the %%BeginData section just might improve > things. The raw image data (binary! w/o escapes!) must follow immediately after the "image\n". The proper fix is simply to add 6 to the byte count. Other random guesses: %%!PS-Adobe-3.0 ... %%%%LanguageLevel: 2 Mismatch? Too high for a very old printer? |
|
From: Micah J. C. <mi...@co...> - 2006-08-19 03:24:47
|
On Fri, Aug 18, 2006 at 10:32:53PM -0400, Albert Cahalan wrote: > > What I think /might/ cause problems, is the fact that the %%BeginData > > section includes a line with the word "image" on it, but doesn't include > > those 6 bytes (including newline) in the specified byte count. I wonder > > if moving that line before the %%BeginData section just might improve > > things. > > The raw image data (binary! w/o escapes!) must follow > immediately after the "image\n". The proper fix is simply > to add 6 to the byte count. Yeah: I'd forgotten that. > Other random guesses: > > %%!PS-Adobe-3.0 > ... > %%%%LanguageLevel: 2 > > Mismatch? Too high for a very old printer? Not a mismatch: the top one is the version of the DSC comments, not the PostScript level. And the printer claims to support LanguageLevel 3. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ |
|
From: Albert C. <aca...@gm...> - 2006-08-19 02:53:51
|
Another idea: http://studio.imagemagick.org/pipermail/magick-bugs/2004-April/001707.html |
|
From: Albert C. <aca...@gm...> - 2006-08-19 02:59:50
|
On 8/18/06, Albert Cahalan <aca...@gm...> wrote: > Another idea: > http://studio.imagemagick.org/pipermail/magick-bugs/2004-April/001707.html On the other hand, that syntax is deprecated: http://mail-index.netbsd.org/netbsd-help/1999/06/18/0009.html |
Thanks for helping keep SourceForge clean.
X