Codecov Report

Merging #1005 (e647f78) into main (f62e051) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1005      +/-   ##
==========================================
+ Coverage   89.28%   89.30%   +0.01%     
==========================================
  Files          19       24       +5     
  Lines        4435     4443       +8     
  Branches      921      921              
==========================================
+ Hits         3960     3968       +8     
  Misses        323      323              
  Partials      152      152              

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f62e051...e647f78. Read the comment docs.

@pubpub-zz What do you think about this change?

It might be helpful to have those symbol mappings in one folder for the following reasons:

1. In PRs, I can notice data-changes more easily
2. During testing / coverage, I can exclude the data and thus get a more reasonable estimate of how good our test coverage is.
3. We can make diffs between the encodings and potentially notice issues more easily
4. If new symbol mappings get added, it's pretty clear where they belong
5. The generic.py is still huge, but not as crazy as before

I think all of those reasons are rather weak, but I guess this is overall more clean?

I was also uncertain if there is a more efficient way to store the data. I was mainly thinking about the speed it takes to load. The storage size is nothing that concerns me at the moment. But I guess reading / parsing a Python file is probably already super efficient.

Some functions, e.g. fill_from_encoding might actually fit better in the codecs part than into generic

@pubpub-zz What do you think about this change?

It might be helpful to have those symbol mappings in one folder for the following reasons:

1. In PRs, I can notice data-changes more easily
2. During testing / coverage, I can exclude the data and thus get a more reasonable estimate of how good our test coverage is.
3. We can make diffs between the encodings and potentially notice issues more easily
4. If new symbol mappings get added, it's pretty clear where they belong
5. The generic.py is still huge, but not as crazy as before

I think all of those reasons are rather weak, but I guess this is overall more clean?

I was not originally happy to add symbol,and other encodings. And this looks clearer : I love it! 😀
perhaps you should also transfer _predefined_cmap and _default_fonts_space_width from _cmap.py

In my fork of PyPDF4, I've tried to restructure the code.
For this I've isolated some very simple objects in a generic1 and I was just importing it into generic to prevent changing the rest of the code :
I've isolated that way quite easily;

class PdfObject(object):                   

class NullObject(PdfObject):

class BooleanObject(PdfObject):

class FloatObject(decimal.Decimal, PdfObject):

class NumberObject(int, PdfObject):

class ByteStringObject(BytesType, PdfObject):

class TextStringObject(StringType, PdfObject):

class NameObject(str, PdfObject):

def encode_pdf_doc_encoding(unicode_str):

def decode_pdf_doc_encoding(byte_array):

Generic.py keeps advance types:

def read_object(stream, pdf):

class ArrayObject(list, PdfObject):

class IndirectObject(PdfObject):

def read_hexstring_from_stream(stream):

def read_string_from_stream(stream):

class DictionaryObject(dict, PdfObject):

class TreeObject(DictionaryObject):

class StreamObject(DictionaryObject):

class EncodedStreamObject(StreamObject):

class DecodedStreamObject(StreamObject):

class ContentStream(DecodedStreamObject):

class ObjectStream(EncodedStreamObject):

class DocumentInformation(DictionaryObject):

class RectangleObject(ArrayObject):

def get_rectangle(self, name, defaults):
def set_rectangle(self, name, value):
def delete_rectangle(self, name):

def _create_rectangle_accessor(name, fallback):

class PdfBaseDocument(object):                           

I've create PdfBaseDocument as an abstract parent to PdfCommon that provides all functions common between PdfWriter and PdfReader ?
Your opinion ?

Sounds good!

Instead of generic1 I would probably use _base or similar.