Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
GCC recommends not using them for a long time and its documentation says:
> These #pragmas have been superceded as of GCC 2.7.2 by COMDAT support
> and the “key method” heuristic mentioned in Vague Linkage.
> Using them can actually cause your program to grow due to
> unnecessary out-of-line copies of inline functions.
Also nobody seems to set USE_GCC_PRAGMAS and sometimes they were
guarded by just __GNUC__ which upsets Clang.
|
|
|
|
|
|
OptionalContentGroup (and make Ref a regular type to do so).
|
|
|
|
We can just use the default copy assignemnt and constructor for Parent
|
|
Also add two enum values in the qt5 frontend to representate no flags
Also mark glib/gtk/cairo system includes so that gcc doesn't report the issues in those headers
|
|
Fixes rule-of-three and copyable-polymorphic warnings reported by clazy.
The default copy constructor and copy assignment operator are
only valid for simple classes so we delete them (i.e. make then not exist)
when we have either a virtual class or a destructor, the code still compiles
so this doesn't fix any bug, it is more a protection for when you think you
can copy a class and don't realize the default copy constrcutor is not doing
what you want and you get crashes. Hopefully this helps us in the future :)
|
|
- Add support for parsing child nodes in the number tree
- Number tree keys do not have to be consecutive numbers. Use
map instead of vector for parentTree.
- Due to performance impact of iterating a map instead of
vector in parentTreeAdd, add a reverse mapping from Ref
to parentTree.
- Add mcid parameter to findParentElement() to enable finding
the parent when there are multiple MCIDs on the same page.
- Move RefCompare from pdfinfo.cc to Object.h so it can be
used by other files.
Bug #103912
|
|
|
|
getChild and appendChild
It's more consistent with other internal API and less confusing.
|
|
Implement parsing of the StructTreeRoot entry of the Catalog. Also, the
Catalog::getStructTreeRoot() and PDFDoc::getStructTreeRoot() methods are
modified to return an instance of StructTreeRoot instead of an Object.
All elements from the StructTreeRoot are parsed except for:
- IDTree: it is a lookup tree to locate items by their ID, which would
be barely useful because the whole structure tree is to be kept in
memory, which should be fast enough to traverse.
- ParentTreeNextKey: This is needed only when the ParentTree object is
to be modified. For the moment the implementation deals only with
reading, so this has been deliberately left out.
StructElem tree nodes from the document structure tree are parsed as a
StructElement instance. Attributes and extraction of content out from
elements are not yet handled.
https://bugs.freedesktop.org/show_bug.cgi?id=64815
|