Text decoding to UTF-8 #40
Conversation
|
should this be rebased from master due to the test files change ? |
|
Yes, I can do that. Sorry, my workflow on this project was pretty messy. I'll do the same with #41 after this one is taken care of. |
|
Actually, my branch already includes the same commits as your master now does, since I had merged aslehigh-fix-tests into it. Does that take care of it for you? Sorry, I've not used Github much and it's kind of confusing me! |
|
I'm wondering where are the good tests because now the master tests are red while those on this PR are ok ? You could use git rebase to rework your local history and push-force the branch again. If not i'll "squash" the commits on merge no sorry. |
aslehigh
force-pushed
the
aslehigh-text-encoding
branch
from
cd25aae to
9572282
Compare
aslehigh
force-pushed
the
aslehigh-text-encoding
branch
from
9572282 to
36793a8
Compare
|
Done. Thanks for the tip, I had never tried I don't know what's wrong with the tests. If I checkout aslehigh-fix-tests on my computer the tests run fine on Python 2.7 and 3.7. (Actually, I don't understand why they were marked as passing before I started, because your original master was failing for me.) |
Previously the data received back from running PDFtk was processed as a bytes object. I have converted it to a UTF-8 string in the run_command() function.
My primary motivation was to resolve a line splitting bug on the Windows platform (resolve issue #38). With this change, the data returned from PDFtk is handled consistently across platforms and can be correctly and consistently split into lines for further processing.
Several other changes were made to accommodate the data now being string objects, instead of bytes objects.