crsp_ra@gsbacd.uchicago.edu (09/20/89)
I'm trying to use MacPaint to draw some icons and I want to paste them into ResEdit. Is there any way to do this? I tried going via the ScrapBook, but it will only paste them in as PICT's. crsp_ra@gsbacd.uchicago.edu -------------------------------------- all opinions expressed here are my own --------------------------------------
lim@iris.ucdavis.edu (Lloyd Lim) (09/20/89)
In article <5460@tank.uchicago.edu> crsp_ra@gsbacd.uchicago.edu writes: >I'm trying to use MacPaint to draw some icons and I want to paste them into >ResEdit. Is there any way to do this? I tried going via the ScrapBook, but it >will only paste them in as PICT's. Copy a 32x32 bit section from MacPaint. Then start up ResEdit and create a new ICON or ICN# resource. Open the icon so you're in the icon bit editor. Hold down the shift key and select the whole 32x32 bit image and then paste. (The shift key makes the cursor act like the rectangle selection tool.) If you don't select the same size image as you're pasting in, the paste will scale (which usually isn't what you want). The selection tool is also useful for shifting parts of the bit image around while you're editing. +++ Lloyd Lim Internet: lim@iris.ucdavis.edu (128.120.57.20) Compuserve: 72647,660 US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616
oster@dewey.soe.berkeley.edu (David Phillip Oster) (09/20/89)
To paste MAcPaint edited images into ResEdit icons: open ResEdit's fat-bits style icon editor. Hold down the shift key. Do a paste. The shift key also lets you sweep out recangles for cut and paste, and move a group of bits around.
eby@pegasus.ATT.COM (Robert P. Eby) (09/20/89)
>> I'm trying to use MacPaint to draw some icons and I want to paste them >> into ResEdit. I think I've done this recently. The trick is to make sure that the selection you cut/copy from your paint program is exactly the right size (32x32). Robert P. Eby UUCP: att!pegasus!eby AT&T Bell Laboratories Domain: eby@pegasus.ATT.COM
crsp_ra@gsbacd.uchicago.edu (09/21/89)
Thanks for all the suggestions. Ed Lai of Apple suggested a very helpful tool he wrote: a DA called "Clipboard Magician" which converts on type of scrap object to another (e.g. PICT->ICON), among other things. It's very nice and is available by anonymous FTP from sumex.stanford.edu. crsp_ra@gsbacd.uchicago.edu -------------------------------------- all opinions expressed here are my own --------------------------------------
hoffman@ux1.cso.uiuc.edu (09/25/89)
Just a thought, but if you open the PICT (after pasting into ResEdit) as an ICON or ICN# resource, that might work. I haven't tried it, but it sounds ok. Besides, an icon isn't that big a thing to copy by hand using the ResEdit icon constructor. Steve Hoffman hoffman@ux1.cso.uiuc.edu
d88-jwa@nada.kth.se (Jon W{tte) (09/26/89)
In article <18300006@ux1.cso.uiuc.edu> hoffman@ux1.cso.uiuc.edu writes: >Just a thought, but if you open the PICT (after pasting into ResEdit) >as an ICON or ICN# resource, that might work. I haven't tried it, Really, please let's avoid the "I haven't tried it and definately don't know what I'm talking about, but..." posts. Try a private mail instead. Of course you're wrong. The PICT format is a byte-code (or integer-code, if you use PICT2) object oriented format, where each byte means "draw a line" or "fill an oval" or something. The ICN# (and ICON) are bit maps (admittedly the PICT format supports bitmaps: If you really lucked out you'd probably see half your icon misaligned or something... But no better than that.) Why not edit the ICON in ResEdit ? h+@nada.kth.se -- Availability == 1 / (Brains x Beauty)
moreland@network.ucsd.edu (John Moreland) (06/27/90)
I am writing code on a UNIX system which outputs images in PICT format. The problem is, at times I need to write the PICT data to a pipe and I thus can not "back up" to re-write the pictSize information which has already whized by hundreds of bytes ago. Does anybody know of a workaround ? I thought, perhaps, there might be a "magic number" (0, -1, FFFF, etc..) that might tell the Mac to ignore the pictSize field and just read till EOF or until it sees the "opEndPic" opcode... All of the programs I have tried get quite upset (with FFFF for example). FLAME ON (Apple?) This "pictSize" info is pretty silly anyway. I have written a PICT parser that does just fine without needing to know how much data is in the PICT file. All you have to do is read PICT opcodes until you hit the "opEndPic" (0x00FF) opcode ! [even EOF would do just fine if you think about it.] Even if you need to know how big the picture is (for memory allocation for example), why not just see how many bytes are in the file instead of using the "pictSize" information ? Even so, files get "munched" and the pictSize info could LIE. The main problem with this info is that it is the only "after-the-fact" data that "needs" to be generated after all opcodes have been writen out. This causes great pain on systems like UNIX (with pipes). Apple tends to be a little shortsighted about such closed designs. Almost all documentation on PICT/QuickDraw, for example, suggests that one would have little reason to know the "guts" of PICT files since "OBVIOUSLY" PICT files are always written on a mac... APPLE, THE WHOLE WORLD IS *NOT* A MAC ! FLAME OFF Thanks, John
sirkm@ssyx.ucsc.edu (Greg Anderson) (06/27/90)
In article <2582@network.ucsd.edu> moreland@network.ucsd.edu (John Moreland) writes: > ............... The main problem with this info is that it is the only > "after-the-fact" data that "needs" to be generated after all opcodes have > been writen out. This causes great pain on systems like UNIX (with pipes). And I suppose that Unix lacks a malloc() function? Try building the entire PICT in memory, then send it to the pipe. > Apple tends to be a little shortsighted about such closed designs. It does appear that Apple programmers are not the only ones who overlook obvious solutions. :> > APPLE, THE WHOLE WORLD IS *NOT* A MAC ! Nor is the whole world perfect. Writing code that works with existing standards is almost always harder than doing an equivalent function using your own data structures. You might not like the way the standard was implemented, but if you want to be compatible, you have to figure out how to code to spec. That, as they say, is life in the big city. ___\ /___ Greg Anderson ___\ /___ \ \ / / \ \ / / \ /\/\ / \ /\/\ / \/ \/ sirkm@ssyx.ucsc.edu \/ \/
russotto@eng.umd.edu (Matthew T. Russotto) (06/27/90)
<WARNING-- BLOOD PRESSURE RISING. FLAME COULD BE INITIATED AT ANY TIME> In article <2582@network.ucsd.edu> moreland@network.ucsd.edu (John Moreland) writes: >I thought, perhaps, there might be a "magic number" (0, -1, FFFF, etc..) that >might tell the Mac to ignore the pictSize field and just read till EOF or >until it sees the "opEndPic" opcode... > You mean like it ALWAYS has, at least since the 128K ROMs? Try 0x7FFF, though it shouldn't matter. >FLAME ON (Apple?) > > This "pictSize" info is pretty silly anyway. I have written a PICT parser > that does just fine without needing to know how much data is in the PICT > file. All you have to do is read PICT opcodes until you hit the "opEndPic" > (0x00FF) opcode ! [even EOF would do just fine if you think about it.] Yeah, but the PICT stuff goes way, way, way back. Like I said, it hasn't been used since the 64K ROMs (and was patched away even there...) > Apple tends to be a little shortsighted about such closed designs. Almost all > documentation on PICT/QuickDraw, for example, suggests that one would have > little reason to know the "guts" of PICT files since "OBVIOUSLY" PICT files > are always written on a mac... > > APPLE, THE WHOLE WORLD IS *NOT* A MAC ! > >FLAME OFF Closed? PICT was a pretty extensible design, and PICT 2 is even more so. The information for writing both has been available for a long, long time. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?
lsr@Apple.COM (Larry Rosenstein) (06/28/90)
In article <2582@network.ucsd.edu> moreland@network.ucsd.edu (John Moreland) writes: >I thought, perhaps, there might be a "magic number" (0, -1, FFFF, etc..) that >might tell the Mac to ignore the pictSize field and just read till EOF or >until it sees the "opEndPic" opcode... Most program do ignore the pictSize field, because starting with the MacPlus pictures could be larger than 32K bytes. > example), why not just see how many bytes are in the file instead of using > the "pictSize" information ? Even so, files get "munched" and the pictSize Because some files contain more than 1 picture (like printer spool files). > "after-the-fact" data that "needs" to be generated after all opcodes have > been writen out. This causes great pain on systems like UNIX (with pipes). > > Apple tends to be a little shortsighted about such closed designs. Just because you can't stream out a picture without backtracking, doesn't make it a closed design. There are lots of file formats that require such backtracking. (Usually when the format is designed to be easier for the reader to process than the writer.) QuickDraw pictures are a native Mac format, and if you want to interchange pictures, then it is best to use a standard interchange format. The picture format is completely documented, but it's not intended to be an ANSI standard. It has changed a few times in the past, and it will probably change in the future. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
mclow@telesoft.com (Marshall Clow @telesoft) (06/29/90)
In article <2582@network.ucsd.edu>, moreland@network.ucsd.edu (John Moreland) writes: > I am writing code on a UNIX system which outputs images in PICT format. > The problem is, at times I need to write the PICT data to a pipe and I thus can > not "back up" to re-write the pictSize information which has already > whized by hundreds of bytes ago. Does anybody know of a workaround ? > I thought, perhaps, there might be a "magic number" (0, -1, FFFF, etc..) that > might tell the Mac to ignore the pictSize field and just read till EOF or > until it sees the "opEndPic" opcode... > > All of the programs I have tried get quite upset (with FFFF for example). [Flame Deleted} > Thanks, > John Just put a 0 in the picSize field. DTS has reccomended this to several developers. Since the picSize field is only 16 bits, and pictures can be _much_ larger than 32K ( or even 64K ), there isn't any way that that field can alwasy be accurate. Marshall Clow mclow@telesoft.com