-1
I don't think any more classes should be publicized,
internals of PoDoFo should rather be protected from
users who might be tempted to rely on them.
Hello zyx, hello Mattia, hello all,
> On 30 July 2018 at 11:03 zyx wrote:
>
>
> On Sun, 2018-07-29 at 19:45 +0200, Mattia Rizzolo wrote:
> > anybody? :)
> >...
> > > |-class PdfXRefStreamParserObject : public PdfParserObject {
> > > |+class PODOFO_API PdfXRefStreamParserObject : public PdfParserObject {
> > > | public:
> > > |
> > > | /** Parse the object data from the given file handle starting at
> > >
> > >
> > > But then I ask, is that class meant to be part of the public API?
IIRC it isn't meant as such, but as an internal part of the PdfParser API (so
the only class of all these is to be PdfParser itself, the other are of no
interest to application developers, aren't they?
> > > Otherwise, something else should be done to allow its linkage even with
> > > -fvisibility=hidden.
Yes, that's the solution I much prefer. I'm sorry to have not researched yet
which facility of ELF shared libs is to be used for that (or I don't exactly
remember, there was some paper of Ulrich Drepper about ELF internals and
security where I may have read such, I can hopefully read up on it in a few
days if nobody else is interested).
>
> Hi,
> I'm afraid nobody has a definite answer for your question, otherwise
> they'd already answer it, though, from my point of view, anything what
> is in public header(s) should be marked with either PODOFO_API or
> PODOFO_DOC_API, thus there are more "affected" classes, namely (from
> those I briefly grepped for): PdfHintStream, PdfFontType1Base14,
> PdfFontType1, PdfFontTrueType, PdfFontSimple, PdfXRefStream, PdfXRef,
> PdfObjectStreamParserObject, many in PdfEncrypt.h and that of yours,
> PdfXRefStreamParserObject.
IIRC there are some hints in the docs that PdfFont is meant as an
opaque supertype (meaning users aren't supposed to see any subclass,
if such info is really needed there could be a PdfFont::GetFontType()
returning an enum), so every subclass should be moved to an internal
header (to be created) that won't be installed. Same for PdfEncrypt.
The XRef and ParserObject classes, internal to the PdfParser API
implementation, should also also be moved to an internal header.
PdfHintStream is part of the, still broken/deacivated, linearization
support in PoDoFo, so currently unused, but also internal.
>
> Strictly speaking, (even I do not know why there is PODOFO_API and
> PODOFO_DOC_API, when both are defined to the same value) PdfTTFWriter
That class is another one currently unused IIRC, so also to be hidden.
> uses PODOFO_API, but it should use PODOFO_DOC_API instead, because it
> resides in src/doc/, not in src/base/.
>
> I mean I'd be fine with the proposed change and if nobody has any
> objection (and I'll not lost track of this), I'll do the change within
> few days.
> Bye,
> zyx
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
