binmode not needed if we always output bytes

[dginev]

Simple enough (now that we have a proper understanding), all result prints expect bytes now, i.e. the result to be printed has already been utf-8 encoded.

[dginev]

Fixes #926 for latexmlc

[dginev]

well, almost. A certain path through latexmlc still has wide characters as a serialization never gets utf-8 encoded. Which is why I was wondering if we shouldn't put the encode call already in serialize_aux in Document, since I think this is the only serializer that does not explicitly do an encoding to bytes.

The current master branch shifts that responsibility to the executables, notably latexml, which means I need to be extra careful in latexmlc to not skip a case. Luckily some of the tests for the daemon runs test the logs!

[dginev]

Added a commit that should handle things with the current approach.

[brucemiller]

The thing that got us in trouble was the inconsistency: one rare case being already encoded when most other stuff was characters. I'd prefer to keep things as consistent and localized as possible. So, I'm less inclined to change Core::Document's approach. But you're right that latexmlc has to deal with a variety of objects and we need a way to know (or use polymorphism) whether each object is encoded or not.

[dginev]

Wouldn't a convention that any toString method returns an encoded string be more consistent?

[dginev]

The other type of object that latexmlc can return are archives, and that is just binary data, so it follows the result is just bytes convention

[brucemiller]

Oh, I just merged, but probably would like to request a comment to the effect of method is always bytes (similar to what I added in latexml/math, perhaps?)