OpenSystemsDevelopment / qpdf

Commit a531418964d8f3116f5c7d5f7a7966e963e75a70

Authored by Jay Berkenbilt
1 parent 78ad4ad1

TODO: more planning

Inline Side-by-side
Showing 1 changed file with 33 additions and 17 deletions
... ... @@ -2,15 +2,14 @@
2 2 Next
3 3 ====
4 4  
5   -Priorities (could be for 10.x)
  5 +In order:
  6 +* PointerHolder -> shared_ptr
6 7 * code formatting
  8 +* cmake
  9 +* ABI including --json default is latest
7 10 * json v2
8 11  
9   -Priorities for 11:
10   -* cmake
11   -* PointerHolder -> shared_ptr
12   -* ABI
13   -* --json default is latest
  12 +Other (do in any order):
14 13  
15 14 Misc
16 15 * Get rid of "ugly switch statements" in QUtil.cc -- replace with
... ... @@ -41,18 +40,19 @@ big commit to bring everything up to spec. Things to keep in mind:
41 40  
42 41 * clang-format looks promising but is a bit of a moving target; need
43 42 to see if its output has been stable over the past few releases
44   - since the first one that can produce code the way I like it
  43 + since the first one that can produce code the way I like it. I may
  44 + have to require a minimum clang-format version.
45 45  
46   -* Try to match closely to what I have. At a minimum:
  46 +* Ideas here aim for something similar to rust's defaults but with
  47 + adjustments to meet my existing style and preferences:
47 48  
48 49 * 80 columns
49 50  
50 51 * 4-space indent (no tabs)
51 52  
52   - * Probably want to stick with braces on separate lines to minimize
53   - impact, but might consider braces on separate lines for classes
54   - and functions with compact braces for flow control and exception
55   - handling since that seems to be more popular these days
  53 + * Compact braces. While this is a big departure from the past and
  54 + will create many changes, I have become accustomed to this style
  55 + and use it across my projects in other languages these days.
56 56  
57 57 * No "bin packing" -- if arguments (constructor initializers,
58 58 function arguments, etc.) don't fit on one line, do one argument
... ... @@ -124,11 +124,27 @@ messes up searching for things.
124 124 For json v2:
125 125  
126 126 * Make sure it is possible to serialize and deserializes a PDF to JSON
127   - without loading the whole thing into memory. This is substantial. It
128   - means we need sax-style parsing and handling so we can
129   - handle/generate objects as we go. We'll have to be able to keep
130   - track of keys for dictionary error checking. May want to add json to
131   - large file tests.
  127 + without loading the whole thing into memory.
  128 +
  129 + * As with a regular PDF, we can load everything into memory at once
  130 + except stream data.
  131 +
  132 + * I think we can do this by having the concept of generated values,
  133 + which we can make just be strings. We would have a JSON subclass
  134 + whose value is a lambda that gets called to generate output. When
  135 + we construct the JSON the stream values would be lambda functions
  136 + that generate the stream data.
  137 +
  138 + * When we parse the file, we'll have to have a way for the parser to
  139 + know that it should create a lambda that reads the data from the
  140 + file. I think this means we want something that parses JSON from
  141 + an input source. It would have to keep track of the offset and
  142 + length of a value from the input source and have a (probably a
  143 + lambda that it can call with a path) that would indicate whether
  144 + to store the value or whether to create a lambda that retrieves
  145 + it. We would have to keep a std::shared_ptr<InputSource> around.
  146 +
  147 + * Add json to the large file tests.
132 148  
133 149 * Resolve differences between information shown in the json format vs.
134 150 information shown with options like --check, --list-attachments,
... ...