textutil html to rtf vs. TextEdit
I have noticed what looks like a bug in either TextEdit of textutil, but not sure where it is. When I convert html to RTF using the textutil command, the resulting file opens in TextEdit with black text on a black background. It looks a lot like the Safari email creation bug they just fixed with 5.0.1 (yes, I installed it).
Opening the resulting file in TexEdit Plus, Pages, OmniOutliner, Word, OpenOffice all display the file without the black background. I will be reporting it to AppleCare tomorrow.
What I'm not sure about and thought I'd ask here is: do you think the RTF code output from textutil is wrong, or TextEdit is displaying the file incorrectly. Since all the other programs display it correctly, I am tempted to implicate TextEdit, but maybe they just ignore the "background" instruction that seems to be placed by textutil (see below).
If i create a document in TextEdit and save to disk, I get the following code:
{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf320
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\margl1440\margr1440\vieww9000\viewh8400\viewkind0
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx792 0\tx8640\ql\qnatural\pardirnatural
\f0\fs24 \cf0 Hello World}
If I create a barebones html document (see script below) and convert html to RTF using textutil, I get:
{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf320
{\fonttbl\f0\froman\fcharset0 Times-Roman;}
{\colortbl;\red255\green255\blue255;}
\deftab720
{\*\background {\shp{\*\shpinst\shpleft0\shptop0\shpright0\shpbottom0\shpfhdr0\shpbxmargin\shp bymargin\shpwr0\shpwrk0\shpfblwtxt1\shpz0\shplid1025{\sp{\sn shapeType}{\sv 1}}{\sp{\sn fFlipH}{\sv 0}}{\sp{\sn fFlipV}{\sv 0}}{\sp{\sn fillColor}{\sv 0}}{\sp{\sn fFilled}{\sv 1}}{\sp{\sn lineWidth}{\sv 0}}{\sp{\sn fLine}{\sv 0}}{\sp{\sn bWMode}{\sv 9}}{\sp{\sn fBackground}{\sv 1}}}}}
\pard\pardeftab720\ql\qnatural
\f0\fs24 \cf0 Hello World}
What seems to be the big difference is the "background" code -- If I remove it, all is well. It apparently specifies the background for the document, and in this case tells it to be a rectangular shape with various parameters, but if I try changing the shape or fill color it doesn't seem to make a difference.
So I guess the question is why textutil is putting that code in there, and why it screws up TextEdit's display...
(the spec for the parameters is here: http://www.biblioscape.com/rtf15_spec.htm )
Here's an AppleScript that re-creates the problem:
set oFile to "/Users/username/Desktop/oFile.html"
set strHTML to "<head><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\"/></head><body>Hello World</body>"
try
set fDesc to open for access oFile with write permission
write strHTML to fDesc as «class utf8»
close access fDesc
on error
try
close access fDesc
return strText
end try
end try
set strCommand to "textutil -convert rtf " & (quoted form of (POSIX path of oFile))
set strResult to (do shell script strCommand)
Opening the resulting file in TexEdit Plus, Pages, OmniOutliner, Word, OpenOffice all display the file without the black background. I will be reporting it to AppleCare tomorrow.
What I'm not sure about and thought I'd ask here is: do you think the RTF code output from textutil is wrong, or TextEdit is displaying the file incorrectly. Since all the other programs display it correctly, I am tempted to implicate TextEdit, but maybe they just ignore the "background" instruction that seems to be placed by textutil (see below).
If i create a document in TextEdit and save to disk, I get the following code:
{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf320
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\margl1440\margr1440\vieww9000\viewh8400\viewkind0
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx792 0\tx8640\ql\qnatural\pardirnatural
\f0\fs24 \cf0 Hello World}
If I create a barebones html document (see script below) and convert html to RTF using textutil, I get:
{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf320
{\fonttbl\f0\froman\fcharset0 Times-Roman;}
{\colortbl;\red255\green255\blue255;}
\deftab720
{\*\background {\shp{\*\shpinst\shpleft0\shptop0\shpright0\shpbottom0\shpfhdr0\shpbxmargin\shp bymargin\shpwr0\shpwrk0\shpfblwtxt1\shpz0\shplid1025{\sp{\sn shapeType}{\sv 1}}{\sp{\sn fFlipH}{\sv 0}}{\sp{\sn fFlipV}{\sv 0}}{\sp{\sn fillColor}{\sv 0}}{\sp{\sn fFilled}{\sv 1}}{\sp{\sn lineWidth}{\sv 0}}{\sp{\sn fLine}{\sv 0}}{\sp{\sn bWMode}{\sv 9}}{\sp{\sn fBackground}{\sv 1}}}}}
\pard\pardeftab720\ql\qnatural
\f0\fs24 \cf0 Hello World}
What seems to be the big difference is the "background" code -- If I remove it, all is well. It apparently specifies the background for the document, and in this case tells it to be a rectangular shape with various parameters, but if I try changing the shape or fill color it doesn't seem to make a difference.
So I guess the question is why textutil is putting that code in there, and why it screws up TextEdit's display...
(the spec for the parameters is here: http://www.biblioscape.com/rtf15_spec.htm )
Here's an AppleScript that re-creates the problem:
set oFile to "/Users/username/Desktop/oFile.html"
set strHTML to "<head><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\"/></head><body>Hello World</body>"
try
set fDesc to open for access oFile with write permission
write strHTML to fDesc as «class utf8»
close access fDesc
on error
try
close access fDesc
return strText
end try
end try
set strCommand to "textutil -convert rtf " & (quoted form of (POSIX path of oFile))
set strResult to (do shell script strCommand)
MPB (Early 2008) 2.24GHz, 4GB, 200GB SATA, Mac OS X (10.6.4)
