Re: [poppler] Should we aim for having utils only using public API, ideally cpp/ ?
I remember, the reply was something like "you should use cpp-interface". But the coverage of cpp interface is too small to implement yet another OutputDev. Yes the cpp interface doesn't provice that. Though as mentioned back in 2017 to Even, no one says what they really need, just the classes they hope we did not touch. What we need is someone giving us the high level description of their needs so we can try to come up with the API they would need and we could maintain. If there is some example of "the high level description of their needs" which made poppler maintainers reconsider to add new feature, please let me know. I want to learn more. "We want to have yet another OutputDev, because we have our own page description language-like API, we want to have a bridge from PDF to our own PDL-like API, so we want to have yet another OutputDev" might *not* be "the high level description of their needs". But as you agreed, cpp (or other interfaces) is not sufficient to develop yet another OutputDev, so the request by the people trying to develop their own OutputDev would not be resolved. Also, I'll be honest here, lo-end Japanese printer companies are totally at the bottom of my list on "people I'd like to help during my spare time", so even if they gave me the best specification ever i doubt i would decide to work on that over the other 600 bugs we have. "I have no time to work for that" is the most persuasive comment in OSS, rather than "there might be no requirement for that", I think :) Regards, mpsuzuki On 2020/01/15 8:03, Albert Astals Cid wrote: El dimarts, 14 de gener de 2020, a les 6:28:41 CET, suzuki toshiya va escriure: On 2020/01/14 13:56, Oliver Sander wrote: We have asked third party uses of non public headers to come forward and describe their needs multiple times, we've always got a big silence as answer. Not completely true ;-) Indeed. As mentioned I have also received descriptions of what the LibreOffice folks do. In order to import pdf files they subclass OutputDev to 'paint' into a custom internal format they have. I'll dig out the details on request. Best, Oliver I agree with "Not completely true". In the past, OpenPrinting consortium members had asked about the usage of APIs in non public headers, to make yet another OutputDev, as the lo-end printers by Japanese companies (note: some lo-end inkjet printers want to interact with the host machines, so, making a fixed printer data by PS or PDF are not sufficient). I remember, the reply was something like "you should use cpp-interface". But the coverage of cpp interface is too small to implement yet another OutputDev. Yes the cpp interface doesn't provice that. Though as mentioned back in 2017 to Even, no one says what they really need, just the classes they hope we did not touch. What we need is someone giving us the high level description of their needs so we can try to come up with the API they would need and we could maintain. Also, I'll be honest here, lo-end Japanese printer companies are totally at the bottom of my list on "people I'd like to help during my spare time", so even if they gave me the best specification ever i doubt i would decide to work on that over the other 600 bugs we have. But that's just me and we'd be still good to have such specification, once we have that spec maybe they could themselves work on it ;) Cheers, Albert Regards, mpsuzuki ___ poppler mailing list poppler@lists.freedesktop.org https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fpopplerdata=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C7f04c32ffbbd45a4cf0d08d799460e7c%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637146398484229245sdata=J8cv2oPRhpjIpsKMYXufnWgv7KNfJdeZ%2FNff4e41eyk%3Dreserved=0 ___ poppler mailing list poppler@lists.freedesktop.org https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fpopplerdata=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C7f04c32ffbbd45a4cf0d08d799460e7c%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637146398484229245sdata=J8cv2oPRhpjIpsKMYXufnWgv7KNfJdeZ%2FNff4e41eyk%3Dreserved=0 ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Should we aim for having utils only using public API, ideally cpp/ ?
El dimarts, 14 de gener de 2020, a les 6:28:41 CET, suzuki toshiya va escriure: > On 2020/01/14 13:56, Oliver Sander wrote: > >>> We have asked third party uses of non public headers to come forward and > >>> describe their needs multiple times, we've always got a big silence as > >>> answer. > >> > >> Not completely true ;-) > > > > Indeed. As mentioned I have also received descriptions of what the > > LibreOffice folks do. > > In order to import pdf files they subclass OutputDev to 'paint' into a > > custom internal > > format they have. I'll dig out the details on request. > > > > Best, > > Oliver > > I agree with "Not completely true". > > In the past, OpenPrinting consortium members had asked about the usage > of APIs in non public headers, to make yet another OutputDev, as the > lo-end printers by Japanese companies (note: some lo-end inkjet printers > want to interact with the host machines, so, making a fixed printer data > by PS or PDF are not sufficient). > > I remember, the reply was something like "you should use cpp-interface". > But the coverage of cpp interface is too small to implement yet another > OutputDev. Yes the cpp interface doesn't provice that. Though as mentioned back in 2017 to Even, no one says what they really need, just the classes they hope we did not touch. What we need is someone giving us the high level description of their needs so we can try to come up with the API they would need and we could maintain. Also, I'll be honest here, lo-end Japanese printer companies are totally at the bottom of my list on "people I'd like to help during my spare time", so even if they gave me the best specification ever i doubt i would decide to work on that over the other 600 bugs we have. But that's just me and we'd be still good to have such specification, once we have that spec maybe they could themselves work on it ;) Cheers, Albert > > Regards, > mpsuzuki > > ___ > poppler mailing list > poppler@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/poppler > ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Should we aim for having utils only using public API, ideally cpp/ ?
On 2020/01/14 13:56, Oliver Sander wrote: We have asked third party uses of non public headers to come forward and describe their needs multiple times, we've always got a big silence as answer. Not completely true ;-) Indeed. As mentioned I have also received descriptions of what the LibreOffice folks do. In order to import pdf files they subclass OutputDev to 'paint' into a custom internal format they have. I'll dig out the details on request. Best, Oliver I agree with "Not completely true". In the past, OpenPrinting consortium members had asked about the usage of APIs in non public headers, to make yet another OutputDev, as the lo-end printers by Japanese companies (note: some lo-end inkjet printers want to interact with the host machines, so, making a fixed printer data by PS or PDF are not sufficient). I remember, the reply was something like "you should use cpp-interface". But the coverage of cpp interface is too small to implement yet another OutputDev. Regards, mpsuzuki ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Should we aim for having utils only using public API, ideally cpp/ ?
>> We have asked third party uses of non public headers to come forward and >> describe their needs multiple times, we've always got a big silence as >> answer. > > Not completely true ;-) Indeed. As mentioned I have also received descriptions of what the LibreOffice folks do. In order to import pdf files they subclass OutputDev to 'paint' into a custom internal format they have. I'll dig out the details on request. Best, Oliver ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Should we aim for having utils only using public API, ideally cpp/ ?
On lundi 13 janvier 2020 23:02:50 CET Albert Astals Cid wrote: > El dilluns, 13 de gener de 2020, a les 8:49:14 CET, Oliver Sander va escriure: > > I think that this is a worthy goal, but out priority should be guided by > > the APIs that downstream users actually need right now. For example, > > LibreOffice has its own OutputDev implementation, and would benefit from a > > standardization of that interface. > > We have asked third party uses of non public headers to come forward and > describe their needs multiple times, we've always got a big silence as > answer. Not completely true ;-) The below message still holds: https://lists.freedesktop.org/archives/poppler/2017-September/012515.html I also see your answer https://lists.freedesktop.org/archives/poppler/2017-September/012521.html I don't think I answered to it because I hadn't a lot to propose unfortunately. One aspect I didn't mention is that we have support for other PDF capable libraries (build options of GDAL) which offer low level access to PDF objects, so we have abstracted that a bit (the API underlying a Dict, a Stream, a Array, etc... are pretty much equivalent) for the upper level logic built on it. Hence having low level access to PDF objects is valuable to us. As far as contributing something to Poppler itself, that's not entirely obvious as most of what we do is application specific. So for now we have no better choice than "happily" dealing with the breakages of the private API (I'm not complaining. This is in the contract of using it) Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Should we aim for having utils only using public API, ideally cpp/ ?
El dilluns, 13 de gener de 2020, a les 8:49:14 CET, Oliver Sander va escriure: > I think that this is a worthy goal, but out priority should be guided by > the APIs that downstream users actually need right now. For example, > LibreOffice has its own OutputDev implementation, and would benefit from a > standardization of that interface. We have asked third party uses of non public headers to come forward and describe their needs multiple times, we've always got a big silence as answer. Cheers, Albert > > Best, > Oliver > ___ > poppler mailing list > poppler@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/poppler > ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Should we aim for having utils only using public API, ideally cpp/ ?
I think that this is a worthy goal, but out priority should be guided by the APIs that downstream users actually need right now. For example, LibreOffice has its own OutputDev implementation, and would benefit from a standardization of that interface. Best, Oliver ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Should we aim for having utils only using public API, ideally cpp/ ?
Hello, Am 13.01.20 um 00:15 schrieb Albert Astals Cid: > Because i tried to rewrite something simple like pdffonts and we lack lots of > stuff. I think we should aim for a complete public API. And it seems using our own public API in the utils could help us get there. So from a purely psychological perspective, I think this is a good idea. > On the other hand, pdffonts writes the Ref of the font object, which i'm not > total sure it's of great utility. Maybe this is a sign that the pdffonts implementation takes unnecessary shortcuts? This might be a good opportunity to design both the missing API and a cleaner pdffonts implementation... > What do you think? > > Cheers, > Albert > > > ___ > poppler mailing list > poppler@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/poppler > signature.asc Description: OpenPGP digital signature ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
