rinohtype icon indicating copy to clipboard operation
rinohtype copied to clipboard

De-couple source and destination from filesystem

Open bignose-debian opened this issue 5 years ago • 2 comments

The primary Python API for ricohtype (in particular, rinoh.frontend.rst and rinoh.document.Document) assumes reading from files and rendering to files, with paths on the filesystem.

This is not a necessary part of converting formats from one to another, and it makes it needlessly difficult to make rinoh part of a larger flow within an application.

I propose changing the API so that the API does not primarily assume every parsing is done from a file, and does not primarily assume every render will be to an output file.

Docutils, for example, parses from a text (and it is up to the caller how to get that text), and does not assume any files.

bignose-debian avatar Aug 16 '20 04:08 bignose-debian

I would expect, for example to be able to use rinohtype this way in a Python application:

import rinoh.frontend.rst
import rinoh.templates

# Generate the reST content somehow.
source_document = """Lorem ipsum, **dolor** sit amet."""

parser = rinoh.frontend.rst.ReStructuredTextReader()
document_tree = parser.parse(source_document)

template = rinoh.templates.Article()
pdf_content = template.render(document_tree)

# ... continue processing the PDF content ...

The rinoh library could do all this, if the API were de-coupled from assumptions about real files on the filesystem.

The convenience of handling input and output files is very good, but can be provided as a higher-level wrapper to handle the files, while leaving the Template and Document and Parser clean of any such handling.

What do you think? I can help with this, I think this is best for a library intended for use in applications. But not sure if the direction is what you want.

bignose-debian avatar Aug 16 '20 04:08 bignose-debian

You are absolutely correct, of course. I always planned to also offer a friendly API. Due to lack of time, the focus is still on the command line renderer rinoh and the Sphinx builder.

A pull request would be highly appreciated! I don't have a strong idea about what the API should look like in this case, so feel free to suggest something. This StackOverflow questions might be useful: Should I pass in filenames to be opened, or open files?

brechtm avatar Sep 04 '20 18:09 brechtm