NWE has no paticular "own" format?

[hakohugu]

I am still confused...
Is there any special format for NisusWriterExpress file?

When a file is going to be saved, there is no "NWE format" style, I suppose.
Just "plain text" and Word-oriented file formats only.
At this stage, NWE seems to be "Word-file converter" for me....

Is there any special meaning for not-having own format?

[/img]

[JBL]

The "native format" for NWE is rtf. Assuming the people at Nisus can get rtf to do all the things they want it to do, this is a very good thing. It means that you can share files with your buddies who do not own NWE. It also means that if there is some other word processor that recognizes rtf and does something better you can go back and forth between the two.

I have been told that rtf is pretty extensible so that Nisus can probably do what they need to do with it. This seems to be the Nisus philosophy (the native format for Nisus Writer Classic is txt). I am not sure how this works if you edit a NWE document with a word processor that doesn't recognize all the NWE tags but it really can't be any worse than having a proprietary format. What advantage do you see in a proprietary format?

[Renoir]

The "native format" for NWE is rtf. Assuming the people at Nisus can get rtf to do all the things they want it to do, this is a very good thing. It means that you can share files with your buddies who do not own NWE. It also means that if there is some other word processor that recognizes rtf and does something better you can go back and forth between the two.

I have been told that rtf is pretty extensible so that Nisus can probably do what they need to do with it. This seems to be the Nisus philosophy (the native format for Nisus Writer Classic is txt). I am not sure how this works if you edit a NWE document with a word processor that doesn't recognize all the NWE tags but it really can't be any worse than having a proprietary format. What advantage do you see in a proprietary format?

The problem with extending RTF is that the extensions are not common to other word processors using RTF. So, if you extend RTF, you lose the ability to share files. If you don't, you can't do "what you need to do with it".
A more severe problem is that RTF is a format built around Word and its capabilities. If you use RTF as the native format you turn out doing stuff the way Word does it. I don't want NW to be Yet Another Word Clone. We have enough of those and they all stink just as bad as Word does.

[JBL]

RTF might be a format used by Word but it is THE format used by Cocoa. If you want things done the way Cocoa does them and you want your documents to be compatible with other Cocoa applications rtf is a good choice. I don't immediately see how rtf forces you to do anything much more word like than be a word processor. Maybe you can give me some examples?

As to the extentions breaking when you go to another word processor, sure that is a problem, but (as I noted above) it is hard to see how that is any worse than a proprietary format. The worst case is that people open your files in TextEdit and see garbage, right? Which I don't see as being any worse than not being able to open them at all. If they can see anything other than garbage that is an improvement. The way it worked in NW Classic was that any text editor could see the text but could not see the formating. I imagine that with an extended rtf version of NWE would other word processors could see the text with the style options from regular rtf but not the added options. How is that worse than a proprietary format?

[charles]

The preferred format for Nisus Writer Express right now is RTF. We chose this format for a number of reasons, the biggest one being that RTF is the most commonly accepted file format among all word processors anywhere in the world right now. That means that you can share your files with anyone, regardless of their word processor of choice. Though RTF is officially maintained by Microsoft, the format does not really constrain how we do things.

Another reason we chose this format, RTF does allow us to extend it to add support for features we want without losing compatibility with other word processors. A significant feature of RTF is that you can include new features in it while allowing other applications to still open the file. Of course, if you use features that another application cannot read then those features will not be maintained, but everything else will come through.

-C

[Renoir]

RTF might be a format used by Word but it is THE format used by Cocoa. If you want things done the way Cocoa does them and you want your documents to be compatible with other Cocoa applications rtf is a good choice. I don't immediately see how rtf forces you to do anything much more word like than be a word processor. Maybe you can give me some examples?

As to the extentions breaking when you go to another word processor, sure that is a problem, but (as I noted above) it is hard to see how that is any worse than a proprietary format. The worst case is that people open your files in TextEdit and see garbage, right? Which I don't see as being any worse than not being able to open them at all. If they can see anything other than garbage that is an improvement. The way it worked in NW Classic was that any text editor could see the text but could not see the formating. I imagine that with an extended rtf version of NWE would other word processors could see the text with the style options from regular rtf but not the added options. How is that worse than a proprietary format?

To start, RTF is a propriety format. It is open, but still the property of its owners, Microsoft, and can be "closed" any time Microsoft would like it closed.
Second, RTF is not the Cocoa "lingua franca" - as a matter of fact, the support for RTF in Mac OS X is pitifully poor and extend to a dozen or so options that TextEdit supports. Nothing more.
Third, the problem with extensions is that they often relate to important options that get lost (ignored) when opening the file in another word processor. For example, if you insert an image to a NWE document and save it as RTF TextEdit will ignore the image (it can't read images). If you save it as RTFD (RTF with a special extension and format) Word will not be able to read the extension command \NeXTGraphic and will therefore be unable to open the document and display the image.
Fourth, there is no feasible way to divorce the special options from recognised options in RTf. You can only ignore them, which, as I've pointed earlier, might seriously limit the usefulness of the document.

[JBL]

Proprietary is the opposite of open. This is from Webopedia's dictionary of computer terms but it coincides with every other use of the term I have heard:

open architecture: An architecture whose specifications are public. This includes officially approved standards as well as privately designed architectures whose specifications are made public by the designers. The opposite of open is closed or proprietary.

I don't get your second point. How is the "fact" that Cocoa doesn't support rtf well imply that the text handling capacities of Cocoa are not based on rtf.

As to points 3 and 4, I ask again: How is this any worse than a proprietary format?[/url]

[charles]

Third, the problem with extensions is that they often relate to important options that get lost (ignored) when opening the file in another word processor. For example, if you insert an image to a NWE document and save it as RTF TextEdit will ignore the image (it can't read images). If you save it as RTFD (RTF with a special extension and format) Word will not be able to read the extension command \NeXTGraphic and will therefore be unable to open the document and display the image.
Fourth, there is no feasible way to divorce the special options from recognised options in RTf. You can only ignore them, which, as I've pointed earlier, might seriously limit the usefulness of the document.

To be fair, RTF defines standard ways of saving almost any kind of feature you might want to save in a word processing format. There are a few things that we use extensions for, but they are very small features or in areas where if they are lost it will not generally be a problem. There really is no reason, for example, that the image thing has to be a problem in Cocoa. The reason I think Apple chose not to store images directly in an RTF file is that it is much faster to use a bundle, which is what RTFD is. So the reason that you have this image problem is not due to the limitations of RTF but because Apple chose to ignore the standard.

-C

[Renoir]

Proprietary is the opposite of open. This is from Webopedia's dictionary of computer terms but it coincides with every other use of the term I have heard:

open architecture: An architecture whose specifications are public. This includes officially approved standards as well as privately designed architectures whose specifications are made public by the designers. The opposite of open is closed or proprietary.

I don't get your second point. How is the "fact" that Cocoa doesn't support rtf well imply that the text handling capacities of Cocoa are not based on rtf.

As to points 3 and 4, I ask again: How is this any worse than a proprietary format?[/url]

RTF is not an open standard (the Webopedia is simply incorrect here). It was not approved by any independent body and is still owned by Microsoft. This makes it a conditionally open standard - it is open, as long as Microsoft wants it to stay open. An example to what might happen with it in the future can be witnessed from various incompatibilities between RTF versions (Word 2.0 cannot open RTF files saved by Word 6.0, and so on). When a standard is truly open, the rights to change it unilaterally are handed over to an independent body. For example, Apple is the owner of IEEE-1394 (AKA FireWire) but it handed the rights to it to an independent body. It cannot add to the standard or modify it as it wills.

As for my second point, RTF cannot be used for text handling, of course, since it is simply an interchange format. Rich text objects in TextEdit (rich NSText) can use RTF as a saving (i.e., interchange), but only a handful of control words are supported.

You should differentiate between the capabilities of TextEdit and the Cocoa text engine. TextEdit is a minimal implementation of options available with that engine. NWE, for example, offers options that do not exist in TextEdit and it is still based on the Cocoa text engine.

[charles]

You should differentiate between the capabilities of TextEdit and the Cocoa text engine. TextEdit is a minimal implementation of options available with that engine. NWE, for example, offers options that do not exist in TextEdit and it is still based on the Cocoa text engine.

Actually, you would be surprised how much of the Cocoa text engine TextEdit reveals. Basically everything you can do with an untouched Cocoa engine you can do in TextEdit. All the other things we do in Nisus are due to our adding those features ourselves.

[Al-Irani]

You should differentiate between the capabilities of TextEdit and the Cocoa text engine. TextEdit is a minimal implementation of options available with that engine. NWE, for example, offers options that do not exist in TextEdit and it is still based on the Cocoa text engine.

Actually, you would be surprised how much of the Cocoa text engine TextEdit reveals. Basically everything you can do with an untouched Cocoa engine you can do in TextEdit. All the other things we do in Nisus are due to our adding those features ourselves.

Then the question is, way NWE dose not allow input of the Arabic/Persian text while TextEdit dose. Why NWE dose not support Arabic Script even on same level as TextEdit?? Dose this means that you have taken away this feature (Arabic script support) of Cocoa text engine purposely??

[Renoir]

You should differentiate between the capabilities of TextEdit and the Cocoa text engine. TextEdit is a minimal implementation of options available with that engine. NWE, for example, offers options that do not exist in TextEdit and it is still based on the Cocoa text engine.

Actually, you would be surprised how much of the Cocoa text engine TextEdit reveals. Basically everything you can do with an untouched Cocoa engine you can do in TextEdit. All the other things we do in Nisus are due to our adding those features ourselves.

Then the question is, way NWE dose not allow input of the Arabic/Persian text while TextEdit dose. Why NWE dose not support Arabic Script even on same level as TextEdit?? Dose this means that you have taken away this feature (Arabic script support) of Cocoa text engine purposely??

My guess is that it this option is indeed turned of, at least for the time being. As to the why, this is another question.

[Renoir]

You should differentiate between the capabilities of TextEdit and the Cocoa text engine. TextEdit is a minimal implementation of options available with that engine. NWE, for example, offers options that do not exist in TextEdit and it is still based on the Cocoa text engine.

Actually, you would be surprised how much of the Cocoa text engine TextEdit reveals. Basically everything you can do with an untouched Cocoa engine you can do in TextEdit. All the other things we do in Nisus are due to our adding those features ourselves.

So the question is: if the Cocoa text engine is so limited and limiting, why use it at all? Why not use your own text engine so you would not be limited to what Apple offers? This would have enabled you to offer all kinds of options (like right to left writing) without being dependant on Apple. Also, when you have to deal with more complex stuff like footnotes and tables, you would have to rely on your own model for text handling so again this would not be useful.

Why use it, then?

[charles]

Then the question is, way NWE dose not allow input of the Arabic/Persian text while TextEdit dose. Why NWE dose not support Arabic Script even on same level as TextEdit?? Dose this means that you have taken away this feature (Arabic script support) of Cocoa text engine purposely??

Sorry for taking so long to reply to this; I've been buried writing code lately. If you have used TextEdit to write in Arabic, Persian, or any other right-to-left language for anything more than typing a few words, you may have noticed that TextEdit is seriously lacking in a number of areas for right to left (notably: tabs).

In OS X 10.2 Apple included a new (private) component that handles some right-to-left. Unfortunately if a developer modifies the text system it usually causes this component to be disabled and we have no ability to access it. We actually spent a considerable amount of effort trying to find a way around this. But, in the end, we finally concluded even if we got this component working again, we still could not offer right-to-left support because Apple's new component is not complete enough.

As you might remember, Nisus Writer Classic is able to support right to left languages because Apple provided support for those languages in OS 9 and earlier. (Not complete support at first, but it was enough that we were able to do the rest.) When Apple debuted Mac OS X, they took away this functionality. The brought back just a tiny portion of it in 10.2 and they should finally be bringing back enough in 10.3 that we will be able to again do the rest. As soon as Apple supports it, we will add support for writing in right to left languages back in Nisus Writer because we know it is important to many of our users.

-Charles

[Renoir]

As you might remember, Nisus Writer Classic is able to support right to left languages because Apple provided support for those languages in OS 9 and earlier. (Not complete support at first, but it was enough that we were able to do the rest.) When Apple debuted Mac OS X, they took away this functionality. The brought back just a tiny portion of it in 10.2 and they should finally be bringing back enough in 10.3 that we will be able to again do the rest. As soon as Apple supports it, we will add support for writing in right to left languages back in Nisus Writer because we know it is important to many of our users.

-Charles

What additions besides right-to-left direction support does 10.3 include?