Overhaul pdfobj

[cormacrelf]

Depends on #175

• 🎉 PdfDict uses an insertion-order-preserving hash map, from indexmap 🎉
• PdfName uses CString under the hood
• Streams and arrays get a much more convenient API, and more things
  operate directly on streams
• Rustified filter_decoded

Note that review is a bit annoying as I abstracted away *mut pdf_obj behing a type alias, PdfObjRef. You can basically click 'viewed' on every file except dpx_pdfobj.rs.

[chirsz-ever]

Do we have a plan to use String everywhere in the near future?

[cormacrelf]

We need to provide &'a CStr sometimes, so that's a non-local change.

[burrbull]

Do we have a plan to use String everywhere in the near future?

Pdf is byte-oriented format, so:

*const i8 -> CString(CStr) -> Vec<u8>(&[u8])

String(&str) where it is appropriate

[burrbull]

lopdf uses LinkedHashMap

[cormacrelf]

lopdf uses LinkedHashMap

linked-hash-map is unmaintained, but they do the same thing, so I went for indexmap. It only takes a few moments to swap them over. I'll push and see what happens to the tests.

[cormacrelf]

Ok, it's much worse. Switching back.

[mulimoen]

I thing the hashmap can hold multiple values with the same key. You could try multimap

[cormacrelf]

@mulimoen Hm? The old linked list code would loop until it found the same key, and replace it, and pdf_obj_release the existing value. If it didn't find any, it would tack it on the end. There were never any dupes. IndexMap has the same properties. It's just a hashmap that preserves insertion order.

[mulimoen]

@cormacrelf I assumed it was using ht_lookup_table, but seems I was wrong.

[cormacrelf]

Ok, I think that's going to pass, we'll see in 125 minutes. But I'm mostly happy.

[cormacrelf]

Well, if anyone can figure out what's wrong, let me know, otherwise I'll try bisecting into multiple PRs.

[burrbull]

It's better to split this PR on several in any case.

[burrbull]

maybe better as_array_mut like in lopdf?

[cormacrelf]

Agree