qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, so I prepared the build system and the integration builds on
Launchpad and the OpenSUSE build service for multiple format support
(basically adding libspectre to the dependencies). Besides the general
review, the (currently empty) files "psmodel.{h,cpp}" await your
PostScript backend. :-)

Best regards, Adam.

P.S.: I have not yet begun the actual integration work itself...

Am 08.01.2013 16:33, schrieb Adam Reichold:
> Actually, I think we could make it (almost) as easy as the
> attached model interface...
> 
> Am 08.01.2013 15:35, schrieb Adam Reichold:
>> Hello Alexander,
>> 
>> After thinking about it for some time, I'd say that I would be 
>> interested in supporting multiple formats in qpdfview if: * We
>> agree to use an abstract document model separating data and 
>> presentation completely. * We agree that the interfaces are
>> modelled on Poppler's interfaces in the beginning, generalizing
>> them later on. * We support at least PDF, PS, and DjVu. * We take
>> our time for the next version which will be 0.4 and no rush 
>> w.r.t. a new name... :-)
>> 
>> Modelling Poppler's interfaces will make it possible to keep the 
>> settings as they are even though some might not make sense for
>> other backends. I attach some sample code on how I would like to
>> proceed with the abstract model. Your thoughts?
>> 
>> Of course, the "fun" part will be adding (probably polymorphic) 
>> interfaces for annotations and form fields which is current
>> missing. But maybe we just make them struct's containing their
>> boundary on the page and a "handler object" derived from QDialog
>> which should make it possible to use the current implementation
>> with minimal changes.
>> 
>> Best regards, Adam.
>> 
>> Am 21.12.2012 12:50, schrieb ????????? ??????:
>>> Hello Adam,
>>> 
>>>>> Ok, it makes sense to create intermediate intefaces for
>>>>> links and maybe annotations, but there is no reason to do
>>>>> it for form fields, as no other format supports them.
>>>> While this is currently so, maybe we want to use a different 
>>>> PDF-backend in the future or there is a new format that does
>>>> this. As I said, we have all the time in the world to do this
>>>> right. If we decide to do it, that is.
>>> 
>>> I don't think that it's right to put all format specific
>>> features to core library. It looks like "early optimization" in
>>> code design. You can spend a lot of time on the things that
>>> actually will never be needed in the future. I'd prefer to do
>>> first so that it just worked. And create common interfaces only
>>> as you need them. On the other hand it may be possible to
>>> create common ancestor class for links, annotations and
>>> everything else and use it everywhere instead of specific
>>> classes.
>>> 
>>>> With "presentation-specific" code, I meant everything related
>>>> to handling displaying content and interacting with it, i.e.
>>>> most of DocumentView, PageItem and PresentationView.
>>> 
>>> Sorry for the misunderstanding.
>>> 
>>> Best regards, Alexander.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJQ7GR9AAoJEPSSjE3STU34Go4H/R+PMccTeuteslzgymmFmtb3
xGoFn57ZnlkLE9tdqhm4vNrjMxFjq8w36ho9w+iVTFopd6sSS977zxAKcufQM9/V
sZCb6QBb6CcsekWfIj6n+JA94jKP9IvKKdgG/jIoZt9C2N5qeM9eVjlULVjqkFM7
Q0MgwUjOi7+fexk0qyEhyoFZxamdwPaDBd1eJ+o8HakIK7qd/m+X7i4z1LplHMbh
s1KFezuI5qSBFtcu4EQNFzFh2ByhroqQG+aa5Ju51VYI9LBjw56NUzyyVZDDH0nO
IjRuMAGB11d32DmxradvyQ2E2C9zOLgSnJzqbF/S0muR5LXw74tUuIbcZKbHNtc=
=uTPb
-----END PGP SIGNATURE-----