gaines@calgary.UUCP (Brian Gaines) (05/27/88)
Have any standards been proposed for files carrying the new text style
information? It would be useful to have an interchange format. I have
tucked the StScrpHandle information into the resource fork of the
associated text file as a resource 'styl' id 128. The file can be read
as plain text by other applns but mine can pick up the style info and
restore it. However, if we all start inventing resource ids there will
be chaos. In the longer run it would be nice if MacWrite, Word, etc
would read up these files.
IT WOULD BE USEFUL IF APPLE SPECIFIED A STANDARD FOR A STYLE RESOURCE
IN A TEXT FILE.
Meanwhile it easy to output MacWrite & Word interchange formats to pass
the style (but not the color!) over. Less easy to reverse the process
as you have to throw away a lot of info.
As an aside, printing the new formats takes little effort - the TEStyleRec
is very neatly structured. Getting scrolling to work correctly without
truncation or garbage bits is more effort. Unfortunately, we have to throw
out the TEAutoScroll of IM IV and go back to our own ClikLoops again.
The pleasure of seeing multicolor, multisize, multifont, multiface text
scrolling around in a document, resizing, word wrapping, etc, is well worth
the effort however.
Tab support and getting over the 32K limit make the final result far
hackier than it need be. Hopefully, these might get into the roms one day.
Brian Gaines
gaines@calgary.cdn
{ihnp4}!alberta!calgary!gainesoster@dewey.soe.berkeley.edu (David Phillip Oster) (05/31/88)
In article <1632@vaxb.calgary.UUCP> gaines@calgary.UUCP (Brian Gaines) writes: >Have any standards been proposed for files carrying the new text style >information? It would be useful to have an interchange format. I have >tucked the StScrpHandle information into the resource fork of the >associated text file as a resource 'styl' id 128. The file can be read >as plain text by other applns but mine can pick up the style info and >restore it. However, if we all start inventing resource ids there will >be chaos. In the longer run it would be nice if MacWrite, Word, etc >would read up these files. This is a real good start. I published an article in comp.sys.mac a while back called "How To Write a TEXT Editor. Part 1" Part 2 was going to be on this very issue. Here are some more points to think about: Sticky Point 1: the diffreent system file problem. 1.) The 'styl' resource has integers for the font-ids. This is a no-no for anything you are going to give to anybody else. You need an additional resource that is a table that maps font-id integers to string font names. Apple does this in 'ictb' resources (see Dialog Manager, Vol 5 of Inside Macintosh.) How about using the Font table part of of an 'ictb' as our file format and storing it in a resource of type 'Font' id=128. (Note the mixed case of 'Font'.) If the required fonts can't be found, the program should probably present a dialog asking how the fonts should be mapped. Sticky Point 2: the old editor problem 2.) Since a user could create a file with a new editor, then change it with an old editor, then open it after the change with a new editor, we have to store some kind of checksum, such as the total length of the text in the first 4 bytes of the resource (for later extension of Text Edit by apple.) in the next 2 bytes should be a checksum composed by XORing each pair of bytes in the text: xorVal = 0; for(i = 0; i < Length(Text)/2;i++){ xorVal ^= ((short *) Text)[i]; } That way, if the length and checksum don't match the program should ask the user whether it should try to use the 'styl' info or not. If this is too garbaged up to use, the user can always close the file and try again. Some menu commands to discard 'styl' info, or to fix it up might be nice. Sticky Point 3: the multifinder compatibility problem: 3.) As long as we are adding resources, remember that the multi-finder compatibility guidlines say that when you open a file, it should come up in the same spot as the screen as last time. (If that spot exists in this systems screen configuration.) I think we should use a 'WIND' 128 resource as a resonable place to put the rectangle of the screen a window should be placed. Sticky Point 4: Other resource that should be in the file: the international resource: INTL 0, INTL 1, and the 'intl' resource that this document requires. The printer job dialog record, I think 'Prec' 128 is pretty much a standard for this. The old editor 'EFNT' and 'ETAB' resources, so that old, single font editors will see soemthing reasonable. Sticky Point #4: If you give users something they'll want to edit it 4.) Remember, if you let the users set fonts,sizes,styles, and colors they'll want to be able to do searches, and search and replaces that are smart about fonts. I've come up with a neat user interface for this, and FullWrite has one also. Note 1: 1.) Note you can use multi-font text edit to implement tabs, by using a special "tab" font, consisting of characters of many different widths. (These have the nice property that they mouse like a tab should, but you have to replace every tab further out on the line as you type in the middle of the line.) Let's get some programns out there! We'll make a standard! Copyright (c) 1988 by David Phillip Oster, All Rights Reserved If you wish to republish this info, please get in touch with me. --- David Phillip Oster --When you asked me to live in sin with you Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu