Forum Archive

Hey all! I hope everybody is having a good day. I'm trying something new this semester. I want to, for reasons of simplicity and personal curiosity, write papers and other writing assignments for my classes in Markdown on my iPad. I already write most of my papers on my iPad as it is, usually in Pages or one of the office suites, so this isn't much of a stretch. The obvious problem with writing these in markdown is that I must get it into a format accepted by my professors. Every one I've ever had insists on one of two formats: RTF or, more often, Docx.

I tried Pandoc for the first time last night and was pleased with the results. On my iPad, I know Daedalus can export markdown to RTF, but I wasn't entirely satisfied with it. That may have been from viewing it in Quickoffice or Office2 HD. The Pandoc method will suffice if necessary, but I would really love to be able to be able to convert it in iOS with similar results.that would be ideal, especially since I take my iPad to class and not my notebook.

Does anybody know of any workflows or pythonista scripts or apps that will do a good job converting markdown to RTF or docx, or even to a format that I can open, formatted, in Pages to do my polishing up, since I can convert from there? For printing, I can just use PDF,more which I have solutions already, and print via Printer Pro, but most of this submitted electronically and very few of my professors have ever accepted PDF for papers and similar projects. Any suggestions?

This works well:

MakeDoc

https://itunes.apple.com/us/app/makedoc/id608833658?ls=1&mt=8

Thanks. I'll check it out now.

Oh, it sounds like exactly what I need. Especially if the dev adds a URL scheme in the future. I'll have to read some reviews on this after class, but it sounds like just the thing. Thanks for the suggestion!

Since you mentioned pandoc specifically, look at

http://wcm1.web.rice.edu/pandoc-on-ios.html

for an online based method for document conversion.

That looks promising. And free since I have Pythonista. I'm very new, like brand new, to Python and pythonista so I'll have to take some time to figure out how to use his extensions there to get output file name prompt, get into another app, like Documents, or anything not GoodReader, or get it to the right place in my Dropbox, and of course, to get docx output. But the author mentions just changing the fields option for that. Thanks for the link!

If you do the pandoc-on-iOS thing, you don't need dropbox. Just write the rtf or docx that you get from Docverter to a temporary file, then call console.quicklook to display the file within editorial. From there there is a share button to open-in Documents (I agree, not in goodreader).

Caution: I wrote a workflow to convert html to PDF using Docverter, but the conversion process consistently lost the last few lines of text.

I'm having trouble with Dropbox anyways and this way sounds better. I made an app for the app key and secret, and it allowed me to login to my Dropbox with the dropboxlogin.py script, but this script is giving error on the last line, output to Dropbox, saying forbidden.

I did notice today that when I run it, it's putting the file in my menu with the scripts in Pythonista. And so I can tell I did get the change of output format from PDF to docx correct, which is good. From there I can select it to view it, and it looks as good as when I use Pandoc on my notebook, which is also good. So I I,aging using console.quicklook will do the same more or less except display it automatically? I'm not entirely sure where to put it and how to implement that and not implement Dropbox. The script is well commented luckily, so I may be able to figure it out well enough without screwing up the important stuff. Thanks for the tip!

Nevermind! I figured out console. Forgot import console first(like I said, I'm very new to Python, but also programming in general, though I have plenty of experience with computers in every other aspect). Just commented out the the stuff (not all, just what would give errors) about Dropbox. Then

import console
Console.quicklook

And where it writes the file with the filename and time stamp, I added the creator's little snippet from the original page instead to prompt for a user-input filename and write to docx:

## Name output file with user input
import console
title = console.input_alert('Output filename', 'Enter title below')
outfile = title + '.pdf'

Later, I will try to clean up the other Dropbox stuff. My main goal now is to make this an editorial workflow and also get a URL to call from Drafts and 1writer. That part should be easy at least, so I'll do it after class. Or maybe during. I've heard it elsewhere, but it does feel good when you get some code to work, at least when you're new to it, even if it's just something small like this, where I was helped a lot by you wonderful people and the man who wrote the script. Thanks for the help, this would have taken a lot longer without it.

One weird thing I forgot to mention: when I get my console preview, the open in is there but selecting an app does nothing. I have to leave the console and enter again. Then it works just fine.

Here's a link to my Docverter workflow which might give you some ideas.

http://editorial-app.appspot.com/workflow/5875045498880000/zKBEqFgCyzc

It names the converted file with the same name as the one you have open in Editorial. And note how you need to delete the temporary files you create or they will clog up your ipad. The workflow has problems, see my comments in the first action in the workflow.

Console.quicklook always works fine for me. I notice your code seems to have console.quicklook after import console. You only need to write console.quicklook when you need to see something.

Okay.mill give that a look. Thanks. I tried console.quicklook by itself at first, unsure how to implement it, and got an error that the module wasn't defined. Then I looked at other modules in the script and noticed how they all had the import function at the beginning of the script, so I tried that and it worked. Having to swipe over to the menu and back into console isn't too much trouble compared with having to leave iOS to do the conversion on my PC in the first place.

I made a Drafts action to call it using the Clipboard and Launch action, since the script takes the text from the clipboard. That worked great from the start. Just need to figure out the Editorial workflow, which, since I have to use url escape before running the script (or calling it via url - I tried both), the final result, the body of the docx document, is still encoded after conversion. Idk, I'll look over your workflow and do a little research tonight. Hopefully the solution will be workable. Though, for the time being I'm okay using the Copy All Text workflow and being manual about it.

While, I do have a fairly good understanding of the majority of actions available in Editorial's workflows, there are still some little intricacies that surprise me. I'm sure there is a logical reason as to why they are how they are though. I got my Workflow to work, well one of them, by calling Pythonista via URL. Before, the final file was encoded, as I said above, but now it is not. The only thing I did differently was move the URL Escape action from just before copying the document to clipboard, to just after (subsequently, just before calling the URL). But it works.

Basically, what I wanted to achieve originally, has been accomplished. Thank you for the help and suggestions. I do want to make it run the script within Editorial in the workflow so it doesn't have to be used with any other apps, but until I get that I can work with this. Though I may buy MakeDoc eventually when I can spare a few dollars, just for the offline crises.

@peterh hopefully this is the last issue for awhile, but though I got it to work in editorial, I still can't get it to open in anything from the console preview of docx file. In Pythonista I can at least leave it and come back into it and it'll work, but in Editorial it doesn't save in the file menu so leaving the console view loses it. So far I haven't found any reason or solution in my research. I can open Documents with the rhttp:// scheme, but unless there's more to the scheme I have yet to find, I would need a link to open it in Documents, and the suggestion on Caleb's site uses the Dropbox link, but I couldn't get dropboxlogin to work. I'm going to keep looking, but if you have anymore suggestions left in you, I'd be happy to hear them thanks for all your help already!

Sounds like you've come a long way in a few days. But it's not quite working yet.

console.quicklook And .docx files

I published a workflow called Share that essentially just calls console.quicklook. Now:

• I made a text file in Editorial and called it test.docx.
• I ran the Workflow called Share.
• Console.quicklook didn't display anything (as expected, it's a text file)
• But I could tap the Share button []-> and tap Documents as one of the options.
• Documents then said the file was corrupted (as expected)

So, this shows that console.quicklook does work with a docx file, and it shows Documents as one of the options. Can you check that the your file has a .docx extension? You can use Print to display your file from Docverter; does it look complicated like a .docx file should be?

Losing the file in Editorial

Editorial puts your files that Python writes in a different folder to where it puts your document files. So you never see them in Editorial.

If you go to Editorial's console and type import os, then things like os.getcwd(), os.listdir(...), os.chdir(...) you will see your lost file(s). Look in the help to see what these do, and what to put in the brackets. Use os.remove(...) to delete unwanted files.

rhttp:// scheme

The idea of this scheme is that what follows the rhttp:// has to be a URL. In Caleb's original script to use Docverter, storing the converted file in Dropbox meant that he could get a URL to that file, and so rhttp:// etc could work. To me the point of using console.quicklook is to avoid messing with Dropbox from a python script.

....

All this probably won't solve your problem. Can you show your code here? Or share your workflow (don't make it public) and put a link to the workflow here, so we can see it.

Here is the link for the workflow. I just got it to work finally. I am going to add some to the workflow, but as far as personal use, this is a nice change. I looked over the workflow you shared with me, and the documentation, and I was able to make sense of a line you had, just before console.quicklook()

outfile_path = os.path.abspath(outfile)
console.quicklook(outfile_path)

Originally, I had

console.quicklook(outfile)

Which allowed console preview, but not sharing. Assign that to the code was pretty much all I needed. I don't know why Pandoc makes all of the headings in docx files blue. Thought that was from the CSS at first, but I recall that using it on my PC gets the same results. Thought that isn't a real problem at the moment. I couldn't get the functions for the os module, mentioned in your post above, to work in console, so I don't know if there is a problem with temp files filling it up or not. I haven't used console much and there is a chance I'm doing it wrong. But I type import os and hit enter. Then I type, say, os.getcwd() and hit enter, but nothing happens. Also did it as os.getcwd( which I think was suggested by the console as I typed it. Beyond that, like I said, I can now share the file to other apps after conversion, and I was surprised to see an encoding error fix itself (thought that's probably not actually the case). On certain files, and only those, and only doing it in Editorial, no Pythonista, the workflow wouldn't work due to some sort of encoding error (which I forgot to write down, and don't recall specifically) but I tried it on those same files just a bit ago after getting it to work and they converted just as well as the others. Needless to say, there is still a lot that confuses me, but I'm happy to see this script has become much less intimidating to look at as I try new things with it. The link is below for the workflow:

http://editorial-app.appspot.com/workflow/5221587699630080/8xIakzmlJV8

I don't know why Pandoc makes all of the headings in docx files blue

It doesn't really – Pandoc simply delegates styling to MS Word 'Themes', and what you are finding is that the default theme on your system has blue headings.

(Switching theme in Word will switch all colors and formatting).

Glad to hear it's all working :-)

Console: in editorial you swipe right to left once or twice, then tap Console at the top. Type at the bottom, hit return and see output at the top. In Pythonista there is a script called shellista (search the Pythonista forum) to work with folders and files. You can also write short scripts in the editorial's python scratchpad to look at files:

import os
print os.getcwd()
...

Your workflow cretates two files but does not delete them. At the end, put:

os.remove('docverterin.txt')
os.remove(outfile)

Also:

• You could try setting the heading colour in the CSS. In an ideal world this would be at the bottom of the cascade.
• We get encode/decode errors because the document has characters outside the common ASCII ones. Google python unicode sandwich. Briefly: put a 'u' in front of strings, use 'codecs.open' to open files.

@rob that must be the default uses by other apps, or in the CSS in the code, because it's exactly the same using Pandoc on my laptop or through Docverter and this script in both Pythonista and Editorial; at least, on my ipad it is. But that would make sense - looking at the Styles on the ribbon in Word, the blue is used, so it is definitely the default theme for it on my laptop at least. I rarely ever use those when I use Word, I forget they're there most of the time. Thanks!

@peterh Thanks for the info! I'll add those, and I'll try that in the console. I was simply entering os.getcwd() without print. That makes sense to add it though, as I think about it.

I saw something the other day in, I think Learn Python the Hard Way, that showed very briefly some strings with u in the example! but didn't go into them at that point. I'll look that up tomorrow and do some thorough research on it.

I thought about the CSS so I will have to look at it too. I've been working on learning some CSS in my spare time, while brushing up on my HTML from years ago. I should be able to figure that out, as long as there is nothing especially different when being implemented in a script, as such. I've learned a lot from this little project though. Every little bit learned - I'll chalk it up as a win and continue with it. Thanks again. I'll be going over this stuff tomorrow when I'm well-rested (hopefully!) and can give it the time it deserves.

Cheers!