We don't need no stinking page numbers!!!!!!!!!

[rpcameron]

I've been following this post, and found a few points that I'd like to make a comment on. Mellel's native format is unfortunately only of use if you are solely using Mellel. If you need interchange with other systems/programs, then you must export to a different format. Ideally that format would be PDF, since it will look exactly as you need it to. Unfortunately, if there is any collaboration going on, that is probably not the best solution.

The next best option is RTF. The reason for this is actually multi-fold, but when you understand it I'm sure you will probably never consider using Word export as interchange and only use RTF. RTF is a plain–text format that is actually owed, maintained and modified by Microsoft. The current version of RTF is also feature complete and equal with the latest version of Word's binary format. If something can be done in Word, it can be saved into an RTF file.

The other reason you'd want to use RTF is because the RTF exporter that Mellel uses is written by the Redlers' themselves. The Word export relies upon the OS X system–wide DOC support, which is not very good, and inconsistent between major versions—OS X 10.4's DOC support is different from OS X 10.5's, &c. Mellel's RTF support will not support every feature that an RTF file may have included, and it is also possible that there are things in your Mellel document that will not be included in the exported RTF. The reason for this is because the program it is used for fundamentally differs from Mellel. Features in Word but not Mellel may be represented in the RTF, but they will not be supported. Likewise, features in Mellel that are not found in Word will not be included in the export.

PDF is still the best option for export and interchange, RTF is going to be second best. There is no reason (realistically) that a Word DOC format export should ever be used.

[ppnkg]

The problem is Textedit, I can confirm similar problems. To expect that TE would do certain things as expected is reasonable, but not all things Apple work as expected.

[este.el.paz]

Gentlemen:

Thank you for the more thorough explanation on the issues inherent in exporting files. I'm sure the programming issues are nightmarish and I understand that. Still, as a GUI jockey I can only report what I'm finding to be problematic and hopefully the frontline trench workers can try to change problems into solutions. As I stated at the beginning when I'm playing alone with mr Mel we're happy. Part of the reason for posting here is to encourage more energy attention to be placed on this area for program development. In the meanwhile, TE is moved to a lower place and other options for adjusting exported RTF's will be searched for . . . .

eep

[jannuss]

if there are no problems in the Mellel file, but when exported they show up, why would we re-import them to look at them in Mellel again?

It actually never dawned on me to try opening a file that I just exported from Mellel, with Mellel . . . it seems obvious now, but why would we export it and then open it from the same program? The problem is not with how Mr Mel relates to himself, but with others; if I use mr Mel to check his own work he says it's fine. The problem is trying to find out how the majority of the world's word processors handle the exported product-

The topic of using Neo Office is mentioned by you above and by others on this and the Yahoo forums--but no details of what they are or you are doing with them are mentioned--so I'm asking about it. It appears that they are used to move files from PC to Mellel and back again--which apparently saves some formatting or citations, etc. But if you are asking why I would need to do that, then why is it mentioned at all? We've completely absolved mellel from all blame in terms of its export/import capability, except we know that problems are still there. Taking your advice to re-import or use Mellel to open an export to RTF, with the extension changed to .doc, I found that the first line was three lines below the top of the page.

OK, I have heard you say that NO translation is ever perfect and that may be the actual answer, we all have to work around that. But, since the exports DO have a few issues--and in this post I was concerned with page numbers, I haven't gone into the whole problem of dealing with citations and bibliographies--we have to try to correct the problems in the exported file--and then we have to SAVE the changes we have made for them to take effect. It's become clear in my contemplation today on the why of using TE, that I can never use TE again--at least with a straight face or when I'm playing with mr Mel; but HOW can we make corrections to our exported products? Is this where the Neo or Open programs come into play?

Thanks for all the help and insights offered. The issue discussed in this post was lost page numbers and that problem has been solved with the suggestion by Nicka that the problem is using TE to make changes and save them

eep,

I read your post this morning just before I left the house and I've been thinking all day how best to reply to it.

I believe we have a very basic misunderstanding here of how the import/export process works and how best to deal with transferring files to PC users. So, rather than actually answer your post, I'm going to walk you through how I understand the process.

Mellel, like most complex applications, stores it's files in a propriety format designed to make the application run efficiently. Also, like most complex applications, Mellel provides users with translators to accepted industry standards, namely flat text, doc and rtf formats.
[iPhoto is a good example of this system. Photo albums are stored in Apple's own format, but users can import/export pictures in standard formats such as jpeg.]

In a perfect world, that would be the end of the story. Unfortunately, our world is far from perfect. Outside factors interfere making it almost impossible to get a correct transfer. Just to mention a few of the problems I regularly run across
-- page size [I work in A4 as do most of my colleagues, but there's always some one who expects US Letter size]
-- fonts [even when I'm careful to use the most common fonts, there'll be some one who has a different font or version with the same name]
-- language [if you use special characters available in the English keyboard, somebody using French/German/Swedish will complain]
-- older system [doc and rtf are "maturing" standards. Endless incompatibilities exist between software running different versions of those standards.]

How to survive? I use one of two strategies
1. quick and dirty: export my document from Mellel in rtf format, transmit it and wait to see what happens. If the user on the other side has problems he'll let me know and I can decide how to deal with them. [Change page size to US Letter, for example.]
2a. long and complex: invite the user on the PC side to join me in defining a document standard that works for both of us.
2b. longer and more complex: when working with a publisher/magazine editor, ask for a copy of their document standard and then define a Mellel style set according to those requirements.

99% of the time strategy number 1 does the job for me.

Because I want to continue using Mellel and continue to make the transfer process more efficient, one thing I never do is modify my rtf files with another application. If there is a problem, I go back into Mellel and solve it there. For example, on a previous version of Mellel there was some issue with tables (I don't remember the details). I went into my Mellel document and replaced the offending table with an image. Later when the Mellel bug was fixed, I was able to restore the table in that document.
If I'd resorted to another application, I would have lost control of what I was doing.

If for some reason I need to check an rtf file before transmitting it, I will need the use of a word processor at least as complex as Mellel. TextEdit is (surprise) a text editor and does not have the capacity to deal with many word processor elements (such as footers and headers). It would be like trying to process a 3D design with a 2D drawing program.

If all I want to do is to check if the file is not corrupted and contains all elements, then reading it back into Mellel is a perfectly valid solution.

If I want to check that the file will transfer to the PC side perfectly . . . well, there is no way to make such a check without having your own PC which is an exact clone of the one to which you are transmitting.

That being said, a WORD clone such as NeoOffice does offer a certain level of security and is particularly attractive since it can be used for free.

Note: NeoOffice is not used to transfer files to the PC. The rtf file created by Mellel is the one that gets transmitted. NeoOffice merely offers an optional check before transfer.

Another note: the trick of changing the file extension from rtf to doc is something I use only very rarely when users tell me they can't open the transferred file [it happens maybe once a year].
Another thing you can do to make life easier for your PC colleagues is to check the "use Windows-friendly attachments" box at the bottom of the attach window when you include the rtf file in an email message. This option removes the OSX data fork which some PC users find confusing.

Finally, let's be clear about this: I am not absolving Mellel of anything. As with most applications, there is a lot in Mellel that needs improving. The rtf translator is not perfect. However, we all know that when dealing with the interface between Mac and PCs, more often than not the problems tend to be on the PC side, but the solution is usually forced on the Mac user.

This is the world we live in.

Janet

[rpcameron]

… I'm sure the programming issues are nightmarish and I understand that. Still, as a GUI jockey I can only report what I'm finding to be problematic and hopefully the frontline trench workers can try to change problems into solutions. As I stated at the beginning when I'm playing alone with mr Mel we're happy. Part of the reason for posting here is to encourage more energy attention to be placed on this area for program development.

Just to clarify, the problem you identified was not a problem with Mellel, but rather a shortcoming in your workflow and lack of a correct tool. The problem was that TextEdit does not support page numbers; therefore, because TextEdit was a component of your workflow, you incorrectly believed page numbers to be lost and attributed this to Mellel's RTF exporter.

We (the other Mellel users) are more than happy to help with solutions to your problems, and believe that as a community we promptly and correctly identified the root of your problem, and provided several options to use as solutions. However, I feel that it is incorrect to attribute this problem to one of program development, because Mellel was not to blame for any part of this problem. I understand it is confusing to someone who does not understand the technical aspects to some parts of the workflow, because they may inadvertently misattribute the error to one program or step over another. Greater education and understand on both sides is the best way to ensure that situations such as this are minimized in the future.

(Janet posted as I was writing this post. I feel that posts such as hers are most helpful, as they explain what is actually going on in a slightly abstract manner, so that solutions to similar problems may also be found, instead of a fix that works only for the immediate situation.)

[este.el.paz]

Janet:

OK, thanks for taking the time to post that information. It was helpful because you understand that there are some issues on the mr Mel end--and you provided work-around solutions to those issues--options. The world is not perfect, mr mel is not perfect, and as you say neither is the PC world--but since they are the majority the burden of proof falls to us.

eep

[nicka]

It was helpful because you understand that there are some issues on the mr Mel end

I agree that Janet's post was helpful, but I think there is a risk that your reply will create a misconception. There are no problems with page numbers in Mellel's rtf export, and the problem you have seen with rtf documents getting scrambled when emailed, again, has nothing to do with Mellel. And these are the two issues you originally raised, I think.

[este.el.paz]

este.el.paz "Taking your advice to re-import or use Mellel to open an export to RTF, with the extension changed to .doc, I found that the first line was three lines below the top of the page. In the Mellel file it started right at the top. So, the question on what programs to use to either open RTF files or import WORD files into first, before importing to Mellel remains."

We could add the question of which programs for "exporting from Mellel" remain as well.

Folks: Like to wind this up, but first a reply to the last two posts which suggested I'm causing misperception to exist about the capabilities of Mellel. Nothing like that has been my intention, I'm reporting as I did on page one that a problem with RTF exports was again discovered by me while following the advice of Janet to open the exported file with Mellel itself, which I did. In this post the concern was originally with page numbers because that happened to be the current problem, which was solved fairly quickly. In that discussion Janet mentioned opening the RTF export with Mellel--which I did, and the quote above from page one shows that there was/is a problem with the RTF export, even when opened by Mellel--Mellel should be acceptable "workflow equipment" right? To test that result I exported another RTF of a Mellel document--the one that is being examined for publishing now, no inline citations, etc to deal with--and in the second export the top line started 4 lines below the top of the page . . . a different result from the earlier export from the same file. This indicates that there probably is a continuing issue in the mellel rtf export translation workflow; again, we're not even going into the inline citation/bibliography situation in this post.

Stating again that overall I'm very happy with Mellel, but the present reality is that Mellel files must be exported into the cruel, subpar standard of WORD, when dealing with trying to get the work into print. Even if the code of Mellel is perfect and totally bug free when creating its documents within the application itself there still could stand to be work done "in the trenches" of the Mellel Guide vis exports. Why not have the material that Janet wrote several posts above that might offer some insight into how to handle the various scenarios that may arise when exporting? That would save a lot of work for her. In my version of the guide I get a simple . . .

Mellel Guide "Note: Some options are not fully supported yet in this version of Mellel. Mainly, style names are not
maintained, and auto-titles are “flattened” when exported.
To export a document as DOC or RTF:
• Choose File > Export > RTF... or File > Export > Word format..."

And that ends the discussion of exports in the guide. Thanks to the Mellel community for the feedback on this topic, hopefully something here will be of some help to others in that community as well.

eep

[nicka]

We could add the question of which programs for "exporting from Mellel" remain as well.

This doesn't make sense, in my opinion. Mellel deals with its own exporting.

If you are asking what applications are worth using to read exported rtf, then that entirely depends on your purpose. In the scenario you have outlined, checking compatibility with Word, if possible you should open the file with a set-up as close as possible to what the final recipient of the file will have. That means Word or a Word-clone like NeoOffice. Even so, if the final recipient has different fonts from you (even if they are different versions of the same font) there may be differences in line-wrap, hence in pagination. You can't reasonably be sure this won't happen so if the _exact_ appearance matters, send a pdf as well. This is the same advice, by the way, that I would give to two users of the same word-processor, even if they are both on PCs, or both on Macs. It's just a fundamental limitation (or feature) of (standard) word-processor file formats that they don't specify the absolute position of text on the page, unlike pdfs or graphical screenshots.

If you were using Mellel to write (say) shopping lists, with a bit of styled text, then TextEdit would be a reasonable place to look at the exported rtfs (as long as you didn't use tables, or numbered/bulleted lists, which are poorly supported by the Mac OS text engine that TextEdit uses).

first a reply to the last two posts which suggested I'm causing misperception to exist about the capabilities of Mellel. Nothing like that has been my intention

I didn't mean to imply that you did it intentionally. I'm sorry if that's how it came across. I just wanted to clarify things for people who might come across this discussion in the future.

I exported another RTF of a Mellel document--the one that is being examined for publishing now, no inline citations, etc to deal with--and in the second export the top line started 4 lines below the top of the page . . . a different result from the earlier export from the same file. This indicates that there probably is a continuing issue in the mellel rtf export translation workflow;

I wouldn't draw that conclusion just yet, even though this is a bit odd. I think it's pretty close to certain that you must have changed something in the file in between the two exports. If we can work out what it is, then perhaps we can see what is causing the funny spacing. Can you reproduce the weird spacing with a minimal file? I mean, if you make a copy of the problematic Mellel file, then delete everything in that except the top paragraph, do you still get odd spacing on export to rtf and re-import?

[Hendrix]

I'm no expert on file formats and so on, so maybe I'm speaking out of ignorance. So, my apologies.

I believe text documents are more and more part of workflows. Inter-application and inter-personal workflows. In my case (and in that of quite a few users, as one can find out in the forums) I start to draft a text in an outliner (OmniGraffle) or on that very nice piece of software called Scrivener... or on a plain text editor like TextEdit or BBEdit, for that matter. I then move it on to Mellel or Word to improve formatting, build a bibliography, a TOC and whatever. It's also part of an interpersonal workflow, since I pass it on to colleagues or merge it with things written by them, often in Word.

At the same time, "complex applications store their files in a proprietary format designed to make the application run efficiently". That means we shouldn't expect all apps to use the same format. OK. But I guess we need a means of exchange that at least keeps some essential elements of the document. The text itself, of course, but (at least for me) the basic outline/heading/autotitle structure of the document as well.

I don't want Scrivener (or whatever app helps to efficiently focus on content and structure) to have any fancy typographical controls. Mellel excels at that and I want to work on that afterwords. But I need it to use a format that at least marks-up chapter or section titles, basic listings, etc. in a way that Mellel understands. I need Mellel to be able to export the document in a format that, although it doesn't keep formatting and type rendering perfect, alows Word to identify basic styles (headings, lists and so on) so that when it comes back to me Mellel can read it and understand without forcing me to reintroduce all the autotitles. It's about separating content and it's structure on the one hand and form/formatting on the other (like html/css is supposed to do), but easing the workflows.

I guess that can't be done now. Am I right?
I guess rtf doesn't allow that. Am I right?
Is there any chance of building it by means of some other format (in a reasonably easy and usable way)?

Regards

Manuel

[nicka]

I guess that can't be done now. Am I right?
I guess rtf doesn't allow that. Am I right?
Is there any chance of building it by means of some other format (in a reasonably easy and usable way)?

My guess: Yes, yes and no. In other words there's no export format that preserves autotitle objects; rtf certainly doesn't, and probabaly couldn't, barring horrendous hacks; and there's not much chance that any accepted format will because Mellel's autotitles are more versatile than the competition's. So there's not much chance of round-tripping documents with autotitles to and from Word for collaboration.

For moving work from Scrivener to Mellel, the prospects are better. What is needed is for someone to write a MultiMarkDown thingie to generate Mellel XML from MMD Scrivener output. I assume that would be a lot easier if RedleX were to publish the specifications of Mellel XML, as promised.

[este.el.paz]

I wouldn't draw that conclusion just yet, even though this is a bit odd. I think it's pretty close to certain that you must have changed something in the file in between the two exports. If we can work out what it is, then perhaps we can see what is causing the funny spacing. Can you reproduce the weird spacing with a minimal file? I mean, if you make a copy of the problematic Mellel file, then delete everything in that except the top paragraph, do you still get odd spacing on export to rtf and re-import?

Nicka: Thanks for the reply. To the best of my knowledge, nothing has been done to change the original file that I made the two exports from . . . . That of course can be checked in "Get Info" but I'm on another machine right now. There would be no reason for me to modify the file, because it had been sent to editor before I posted much of my situation here . . . . And, there has been no reply from that editor since they issued a request for a WORD compatible format from that end--I had sent PDF & plain text doc. Which again brings up the whole, "why should we check the exported file before we send it"? question versus the editor doesn't say why he may have rejected a submission--like text formatting issues that appear when opened in a "foreign" program like . . . WORD. A simple problem may not be overlooked when it helps make the decision between articles written in WORD. Still, I persist in using Mellel as my prime workflow device . . . .
OK, when I get a moment I'll try to reproduce your suggestion of document with everything removed except top paragraph and see what shows. I'll start a new thread when I do that. What will this test demonstrate?

eep

[DanZac]

Sorry for not following this thread. i just opened it up and saw my name.

My use of Google Docs is pretty basic but effective for me. To get the document into Google Docs:
-export as .doc
- open in Word
- Save in actual .doc format
- upload to Google Docs

I then get my advisors or partners to read the doc online and mark up as necessary. I make the changes in Mellel. Content, spelling, and grammar tend to be the issues discussed in collaboration, so I don't get too worried about footnotes and citations not looking correct in Google Docs.

[Hendrix]

Sorry for not following this thread. i just opened it up and saw my name.

The thread's name is somewhat misleading... I certainly need page numbers.

My use of Google Docs is pretty basic but effective for me. To get the document into Google Docs:
-export as .doc
- open in Word
- Save in actual .doc format
- upload to Google Docs

I then get my advisors or partners to read the doc online and mark up as necessary. I make the changes in Mellel. Content, spelling, and grammar tend to be the issues discussed in collaboration, so I don't get too worried about footnotes and citations not looking correct in Google Docs.

That works fine, and other options like the upcoming http://www.textflow.com look promising. But if you work with structured documents (headings, lists, etc.) the great thing is that at least the basic markup or styles is kept between GoogleDocs and Word. The bad thing is that they get lost ("flattened") between Word and Mellel.

Would it be feasible to enable Mellel to export to .doc or .odt without "flattening"?
Would it be feasible to make Mellel read/import -doc or .odt docs mapping at least h1-h6 to autotitles?
I don't need/want all the typograhic details to be kept, that's Mellel's job, and it does it fine.

By the way some kind of odf support will become more and more of an issue, at least in Europe.

[jannuss]

I know very little about Google Docs, but for work directly with WORD rtf a much better option.

Janet