render should accept any writable IO object

[mojavelinux]

The render method should work with any writable IO object. This is good for performance as it allows writing to any stream. The method currently works with most streams, but not STDOUT (a very common choice). It's not possible to use STDOUT because the code attempts to invoke size on the IO object.

.../lib/pdf/core/document_state.rb:69:in `block in render_body':
    undefined method `size' for #<IO:<STDOUT>> (NoMethodError)

We've worked around this problem (in Asciidoctor PDF) by wrapping STDOUT in an object that tracks the length written and responds to the size method. However, it would be reasonable for pdf-core to keep track of the length it has written internally and avoid the call altogether.

The test case should check whether STDOUT can be successfully passed to the render method.

[packetmonkey]

@mojavelinux Thinking about this I came to a similar conclusion, if we could wrap the output IO object with something that tracked all writes, it should work. For the diff to be minimal a Decorator object could be written to wrap the passed IO object that implemented the #<< method and tracked the size of the data as it passes though to the wrapped object's #write method.

I'm totally open to merging a PR for this.

[mojavelinux]

I'll try to put together something asap. I've assigned myself the issue.

[pointlessone]

I took a quick look and it doesn't look like there's an easy way to achieve this.

The problem is that PDF format requires writing some offsets at the end of file. Currently this is implemented by querying size of io object at certain points. This only works if io is empty at the beginning of serialization (which is a bug and probably can produce invalid PDF if non-empty io is passed in).

STDOUT is almost never empty. When you fire a terminal and it presents a prompt your STDOUT is already has something in it.

One solution to this is to cache io (STDOUT) position at the beginning of serialization and subtract that when offsets are calculated but this can be messed up if for whatever reason something will write to STDOUT during rendering. For instance, if you enable warnings and redirect STDERR to STDOUT.

The last example also presents the danger of producing invalid PDF since STDOUT is essentially a shared IO. It's not under exclusive use of Prawn and can be written to at pretty much any time.

Another solution might be an internal buffer (say, a StringIO) that is used through out the whole rendering and only after it it's dumped to whatever io object is passed in. This way we can easily calculate all the offsets as we do now, the io object would only require one write method and that's it.

I will try and sketch the last approach soon if this is still an issue that needs to be addressed.

[pointlessone]

@mojavelinux @packetmonkey Could you please take a look at my last comment as well as #25?

[pepa65]

The internal buffer approach is obviously the right one. As to using stdout, that's a user's choice, and they get to keep the results. There is obviously a demand..!

[pointlessone]

A fix for this has just landed.