qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

Well, been a busy day: I finished the first round of integrating the
abstract model. Comments and especially testing is very much
appreciated. There are probably some issues with integrating format
differences into the UI which have to be solved by further plumbing...

I am looking forward to integrating the PostScript backend! Is there
anyone interested in maintaining the DjVu backend?

Best regards, Adam.

Am 08.01.2013 19:25, schrieb Adam Reichold:
> 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)

iQEcBAEBAgAGBQJQ7JXeAAoJEPSSjE3STU34/jwH/RGSZw6iv9Sc1M6fF9kZDYYf
qN79MBAu6zijmkskZrEO3a/btKrlwL56kCCE3XUifZVceLhzIlB0IiOIsb8NQTAG
Qt89715dgc5MNB1LLjgqQwePqGBY39S8ULmuU0TqeqpcRqhAM10gftjAWIFTwMcS
ciEWiU4CSmsCrwTRGsQ1soRkBFoisFEDoFNuuJ1Qa2RYwgmoWzaydYCEjhiGxmzr
PvE+mlNnhGIf5/A0SZyAXpF4rXJWXUtesOVMi/skkO82u7zMMU2Suk56blNDHKmp
1BB9AVWeSLRf2qrObX7G6VyHvhzsVVIFDwoDjcmrkvSb8XXW0OikX87m7gaHJYg=
=Fm8a
-----END PGP SIGNATURE-----