Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!riley From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley) Newsgroups: comp.sys.amiga Subject: Re: Dpaint fonts... Message-ID: <7635@batcomputer.tn.cornell.edu> Date: 29 Mar 89 14:10:29 GMT References: <13835@gryphon.COM> <7564@super.ORG> Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley) Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 70 [doesn't any part of the uncivilized world get netnews?] In article <7564@super.ORG> rminnich@super.UUCP (Ronald G Minnich) writes: >In article <13835@gryphon.COM> richard@gryphon.COM (Richard Sexton) writes: >>You can tweak the scale with iff2ps to make the aspect ratio anything >>you want. >IFF2PS can't drive a paintjet. iff2ps doesn't come with Deluxe Paint. >It seems that every solution I have seen to using deluxe paint involves >hunting around for some public domain goodie and and hoping that >somehow you can get printed output that looks like something. >Tell me what you will, but MacPaint output to an Imagewriter looks >better than DeluxePaint to almost anything- unless you are willing >to do a *lot* of screwing around. Why is this? I dunno. Why is this >after *3 years*? I dunno. I think it is your fault. :-) MacPaint works with the Imagewriter right out of the box because the Macintosh only supports two printers. Supporting a lot of printers costs you some complexity. Despite that, you can get good looking output from DPaint without a lot of screwing around. Prior to 1.3, it was harder, and it was DPaint's fault for not allowing a decent amount of control over the printer device parameters--so you needed something like Andy Finkel's "Control" program which allows you to intercept and modify the DumpRPort() call from DPaint. With the improved printer drivers and preferences in 1.3, you can get good looking output (well, at least competitive with MacPaint on a Imagewriter) fairly easily--you just have to understand the options in preferences and how they interact. THIS IS NOT HARD. You may have to print out a few pages with different options to see how they interact with your particular printer, but once you've done it once, it's done. The Amiga does need better postscript support, and Commodore and third parties are going to have address this in a serious way, and soon. Commodore did a great job in 1.3 addressing most of the complaints about printer support; I expect they are at least thinking about postscript support for some later release. >>Thats a valid complaint. Saying Dpaint is useless isn't It does what >>it does very well. >Well, I guess you are right, it does what it does ... well, ok maybe. >Fact is that Amiga people always end up stacking dpaint up against >the competition. That's not fair, i know, but that is what happens. >And we always seem to lose. Do not. I'll take DPaint over most of the Mac paint programs any day. Comparing it to a Draw program obviously isn't fair, which seems to be what you're doing. If so, I can only echo Richard--DPaint isn't a structured graphics editor, it's a bitmap editor. If you want a draw program, don't look at DPaint. We do need a good draw program, and we need some hybrids--things that will let you do structured graphics on top of a bitmap. But don't expect DPaint to do it all. >Yeah, but Richard, I don't even want that much. Neither did the >original poster. He probably drew, maybe, a box or a triangle, >and noticed that when he printed the triangle it looked like sh*t. >As did lots of people three years ago. For drawing and printing >the most basic pictures dpaint fails. One more time. DPaint is an excellent bitmap/pixel editor. You can do a lot of nice things with it, but it has limitations (and features!) that are inherent to a paint program. If you want a draw program, complain about the lack of draw programs, don't complain that dpaint isn't a draw program. DPaint is very good at what it was designed to do, and a lot of people get a lot of utility out of out. But it's not going to solve everyone's problems. Get the right tool for job. This is getting suspiciously close to a flame, so I better shut up now before I violate my personal "no-flame" policy. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab.