Add support for base64 encoded images

[francoisfreitag]

Allows constructing documents with images that are not available publicly over the Internet.

[jdufresne]

Can you explain the advantage of this approach over supporting base64 data URLs?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs

[francoisfreitag]

I did not think of using base64 to encode the image, that offers the advantage of using existing mechanisms rather than implementing a custom one, with its set of issues such as uses the data-html2docx-image attribute, and checking the image presence in the imagesdict.

The only advantage I see to accepting BytesIO is that it avoids converting back and forth to base64. I prefer to build data URLs support.

[francoisfreitag]

Now supports base64 encoded images.

[jdufresne]

Nice!

[jdufresne]

If you're interested, we could contribute to typeshed to avoid this type cast.

[francoisfreitag]

I looked into this option. urlopen() returns either a HTTPResponse or an addinfourl. Both implement a read() that returns bytes. The return type used to be specified as the Union of both types, but returning a Union type is discouraged and the urlopen() was changed to return type Any.

An option might be to use structural subtyping and create a Protocol, so that methods common to addinfourl and HTTPResponse are hinted correctly. That would cover the read() method and probably a few others, but adds a maintenance burden.

[francoisfreitag]

Changes:

• Only check for RFC_2397_BASE64 in the header. To be even stricter, look for substring ;base64,, as the grammar defines that parameter is only allowed right before the comma. The suggested patch would error when there was no comma in the data url. Add test_inline_base64_marker_in_data(): to cover suggested case and test_inline_missing_comma.

https://tools.ietf.org/html/rfc2397