Excel for Mac 2011 uses the same default file format as Excel 2010 and 2013 on Windows -- XLSX -- so you don't need to convert your file to a different type when sending it from a Mac to a Windows PC.
![How to convert a txt western mac os roman windows crlf to an excel fil for mac download How to convert a txt western mac os roman windows crlf to an excel fil for mac download](/uploads/1/2/5/3/125364916/367688402.png)
I just discovered, to my great relief, that TextEdit can convert rich text constructed using the native Cocoa text, font, and style features (including lists and tables) to HTML by selecting the proper setting in the Open and Save tab of TextEdit's Preferecnes window. This preference has been available since at least 10.4.6, but I don't know how long before that. Any of you who've struggled with converting Word documents to HTML over the years know what a pain it has been. Word insists on inserting invalid - or simply overly heavy-handed - CSS styles in order to produce HTML that matches the look and feel of the original Word document, and to my knowledge, it provides no way to bypass this. Not to pick on Microsoft unduly, as Apple takes the same approach with Pages, which converts its beautifully-formatted documents to HTML using CSS styles so verbose and convoluted (yet so WYSIWYG accurate) that no self-respecting webmaster would ever want to claim ownership of the code, much less actually post it on a server.:-) Through some extremely difficult maneuvers, it's possible to convert a Pages (or Word) file to HTML, open it in TextEdit, and save it two or three times in order to cleanse the file of its nonstandard and genuinely ugly underlying code. Ending up with an HTML file clean enough to actually work with.
But I wouldn't want to do that on a regular basis! Instead, what I discovered is that if you work in a native Cocoa application like TextEdit using only the tools Apple provides for word processing (which admittedly take some getting used to, and handle only basic formatting needs - much like basic HTML itself), you can easily work in a WYSIWYG mode and then convert the file to clean HTML that you won't be embarrassed to call your own. (For any geeks among you who'd like to learn more about the Cocoa text system,.) Yes, there are many native HTML editors for the Mac that can do this as well - which don't likewise introduce extraneous code - but I was delighted to find I could basically develop HTML in any native Cocoa app as well! For example, I currently do a lot of data entry in DevonThink Pro, which - like SohoNotes, Journaler, Yojimbo, Curio, VoodooPad, and many others - enables word processing through the native Cocoa toolset. If you do the same, you'll find that you can build tables, lists, and any other text you like in such an application and then, if you need to convert it to HTML, simply copy and paste it into TextEdit.
You don't need to export the file to RTF or HTML or whatever from the application in question. Until yesterday, I thought TextEdit's HTML conversion ability was on a par with that of Word and Pages. That's probably because in its default mode, it is. However, unlike those apps, the surprisingly powerful TextEdit provides some very handy, simple options to produce clean HTML when you need that.
Here's a brief set of steps to take advantage of this capability:. Copy and paste your Cocoa-formatted text into a new TextEdit document. (Hint: TextEdit provides an Application Service (New Window Containing Selection) in the Services menu for this once you select the text in the originating app.). Open TextEdit's Preferences and select the Open and Save tab. Change Document Type to either HTML 4.01 Strict or XHTML 1.0 Strict, depending on whether you want your code to be compliant or not. Change Styling to No CSS.
Note that this will strip all font and style information from the file, except for the basics like bold and italics. From the TextEdit menubar, select File/Save As. In the Save As dialog box, give your file a name and hard disk location.
Then, change the File Format selection to HTML, and click Save. Now, when you click on your new HTML file in the Finder, it will open with your default web browser. If you examine the source code, you'll see nothing but simple, pure HTML (or XHTML). The only 'bad' thing I noticed was that the Cocoa HTML Writer that does the conversion still uses for boldface rather than the 'correct'. But that's easy enough to fix.
If you're like me, you can now take the HTML code and plop it into your blog post or any other standard HTML file (which probably already has its own CSS styles defined), and it will add nothing but pure content to that file. This is going to be a real time-saver for me, since it'll let me format lists and tables in any Cocoa app and not have to worry about how I'm going to convert the data to HTML later on! Sigh, this is a classic problem with all too many programmers, or at least those in the paid, corporate world. (I'm looking at you Microsoft.) Give them a simple problem, and they'll make it more complicated to create a challenge and add job security.
Llscots is right. Quite often we don't want to move the WYSIWYG formatting to another document, we just want to move HTML or character/paragraph styles along with the text. I don't know how many times I've tried to drive home to developers the point that we want to leave fonts and other 'how it looks' issues in the hands of the IMporting application. Ideally, the EXporting application shouldn't even include them. I almost had a book go to print with some weird, brief passages in Times Roman (the virus font) that Word didn't strip out when it exported rtf and that InDesign didn't strip out when it imported rtf.
Earlier this week I evalutated Mellel, a lightweight but powerful word processor that makes very effective use of styles. I gave up getting it when I discovered that Mellel's rtf export strips out Mellel's styles and just created raw, highly formatted text. And that's a small company that I talked with over and over about the need to export the styles they're so proud of inside their application. And yes, it can also export in XML now, but importing XML into InDesign is poorly documented and needlessly complex. All I want are character and paragraph style tags (which could also be HTML tags). They could hire probably hire a bright 12-year-old who could code that. And that's the problem.
It's too simple and straight-forward. It's much more fun to muck about with all sorts of complex coding to recreate the 'look and feel.' What we need is a text editor that simply tags text, tagging both paragraphs and sections of text (i.e. With italic).
On export it writes those tags out in a form other applications understand, HTML for the web, RTF for Word, MIF for Framemaker, IDIF for InDesign and so forth. For simply transfering style names, that's a trivial task. InDesign's interchange format for paragraph style names is almost identical to HTMLs. Then when we've imported that styled text, it's easy to give meaning to the styles.
This application could also be smart enough to change styles names between import and export. Heading 1 in Word/RTF on import, could become H1 for HTML on export. That'd let us interchange documents in HTML, Word, InDesign, Framemaker or whatever without having to cut out a lot of useless formatting clutter. There seems to be some disagreement over the assertion I made about being 'correct'. Just so you know I didn't make that up, check out the on this subject. I'm sure that my sensitivity and technical training in web accessibility issues is where I got the impression that is preferable to these days.
In any case, it's irrelevant to the hint, though obviously someone at Apple should decide if adhering to web accessibility standards is the more important factor in deciding how to translate a boldface font tag. I don't honestly have a strong opinion myself and can see both sides of the debate. I thought the issue had been decided by w3c's position, but perhaps it's still subject to debate. Cheers, Leland - Anything great you do today can always be improved upon tomorrow. Speaking of TextEdit - which is my most used app after Safari, and does a lot of clever tricks (for instance, paste a URL into TextEdit, select it, control-click and you can make it into a clickable live link, very useful in the myriad help documents I create for clients) - it's not widely known that it's what amounts to open-source; the source code comes with XCode Tools (in /Developer/Examples/AppKit/TextEdit) with, I gather, permission to do whatever you like with it. One neat example of what can be done is, which adds a few neat features (page numbers, columns, header/footer, footnotes, adjustable margins, etc.) to make TextEdit into a pretty good slim & fast word processor - sorta like WriteNow for OS X (except its file format is non-propretary RTF, just like TextEdit).
Hmmm I've been reading through this trying to find an easy Text to HTML conversion programme such as the one I used under OS9 and no luck! I used a small utility called Cyrk Text Converter which is fantastic but doesn't run under OSX and I can no longer run the Classic environment (guess why). Basically all I want to do is convert the URL to the standard link. I tried your offer but no go, when you Control-click on a valid HTML link eg, in TextEdit the link does not get converted.
Instead I get a bunch of option to add or take away styles of one kind or another.I have all the prefs set correctly to save as HTML (actually XHTML). Another writer asserted that if I save as HTML from Textedit I would find a valid HTML doc at the other end. Worse, Textedit adds in para breaks as well as the existing BRs, so I end up with double-spaced docs.Why is such a simple thing beyond all programmers (except the guy who wrote Cyrk)?Bill.