render should accept any writable IO object about pdf-core HOT 6 CLOSED

A fix for this has just landed.

from pdf-core.

@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.

from pdf-core.

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

from pdf-core.

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.

from pdf-core.

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

from pdf-core.

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..!

from pdf-core.