This adds support for PDF output, but a breaking change is necessary since we
are now exposing the raw bytes returned by pandoc instead of first trying to
decode them as UTF-8. This step is unnecessary since it will usually be a no-op
and will fail in case of binary formats.
Alternatively, we could introduce a new PandocOutput variant (e.g.
PandocOutput::ToBufferBinary) for binary output which turns out not to be
valid UTF-8. Then we wouldn't raise a UTF-8 decoding error but would simply
return the raw bytes in this variant instead. This would retain the neatness of
the current API which gives you a String when it's possible and raw bytes
when not.
This adds support for PDF output, but a breaking change is necessary since we are now exposing the raw bytes returned by pandoc instead of first trying to decode them as UTF-8. This step is unnecessary since it will usually be a no-op and will fail in case of binary formats.
Alternatively, we could introduce a new
PandocOutput
variant (e.g.PandocOutput::ToBufferBinary
) for binary output which turns out not to be valid UTF-8. Then we wouldn't raise a UTF-8 decoding error but would simply return the raw bytes in this variant instead. This would retain the neatness of the current API which gives you aString
when it's possible and raw bytes when not.