Dr. Jansen, On Sun, Dec 13, 2015 at 6:34 PM, Dr. Rolf Jansen <[email protected]> wrote:
> Am 13.12.2015 um 19:59 schrieb Riccardo Mottola < > [email protected]>: > > Rolf wrote: > > Ricardo wrote: > > Rolf wrote: > > > 4. PDF readiness > > My application requires reading and flawless display of PDF files, as well > as generation of PDF files from its view contents, some of which may become > really huge. Does this work with GNUstep on Windows? > > > I would say no, I am not aware of native PDF handling on windows. Do you > know what The Cocotron uses? > > > Cocotron does the whole PDF handling (parsing, reading, writing) by > itself, using its Quartz2D replacement named Onyx2D. Recently I committed a > minor fix to the PDF generator. > > > Interesting, is this in-house of cocotron or does it has an external > library? > > > Onyx2D works completely without external libraries, even the rasterizer is > internal code. The internal rasterizer is somewhat slow (a little faster > than pixman+cairo) but way slower that Quarz2D, so people who need speed > can include the AntiGrain rasterizer as an external library, however, > Cocotron works well without any external dependency — it is completely > self-contained. > I find it interesting that Chris not only had time to write a complete clone of Cocoa, but also a complete PDF implementation as well. GNUstep could theoretically use the same code it uses for GSPdf to support PDF viewing. I do apologize. PDF viewing is possible on Linux, but not on Windows currently. > We support most PS functions instead > > > Well, the way from PS to PDF is not that stony, having some hope now. > > Please let us know how we can help. > On GNUstep you have two kits: PDFKit and PopplerKit which rely on xpdf and > poppler libraries. Or you can GSPdf's approach to work with ghostscript. > I got none of the above working on windows yet, not because of the GNUstep > code, but because of the dependend library/application. > > > Well, this sounds not that promising. I have to evaluate this. One option > might be to switch from a PDF to a SVG workflow. Recently, I wrote a SVG > generator for a non GUI server application. SVG is less complex than PDF, > and I guess that I will be able to implement a simple parser and writer in > my application. > > > Actually, perhaps those libraries can be ported. I will try one of these > days. > PDFKit needs some revamping, but my efforts to update it to current xpdf > were unsuccessful, apparently they removed some functionality it relied on. > If PDFKit suits you, maybe it is worth improving it as well as > corresponding GS support. Maybe you can try on Linux first. > > > Certainly, I will evaluate the options. I need PDF import for directly > displaying it in some views of my application and PDF export of the > document view for file exchange with third parties, I don't need PDF > manipulation. > > Does GNUstep provide complete RTF compatibility, editing and display. … > > > Our RTF support is quite good. … > > > The formatted text is kept within my application. Interoperation of > formatted text with other applications is not necessary. > > > Formatted text inside your application should really work quite well! That > is, AttributedStrings are quite capable. To exchange stuff between apps I > would rely on that. You can copy a piece of a web page from Vespucci to Ink > and it is quite good. > > > OK, this sounds promising. > > Is cocotron mantained actually? > > > Yes, it lost a little bit of inertia over the years, however, definitely > yes. > > Partly, from my understanding, because it depends on an undocumented feature within Xcode to allow plugging in SDKs that can change at any time. > We actually always suspected and even have the proof that they copied > stuff from GNUstep circumventing the license. > > > Well, I recently saw on the list that GNUstep people have a habit to > suspect this about other projects, in that case somebody suspected that > Microsofts WinObjC might be a stolen clone of GNUstep. When reading this, I > browsed the code in the GitHub repository, and at that time I found no > indication that they took code from other projects, neither from GNUstep > nor from The Cocotron. > > WinObjC uses Cocotron header files all over the place. You should take another look at the code and you'll see what I mean. > The Cocotron received many small code contributions from many developers > over the years. I cannot speak for everybody, however, I am sure that > Christopher Loyd (who is the initiator and maintainer of The Cocotron) > would cut off his right hand before he would steal code from other > projects. I also contributed some pieces to The Cocotron, and I took > nothing from GNUstep. > I have, in the past seen references from other developers comparing Cocotron code to GNUstep code. I can provide examples of this if needed. While there is no evidence of direct copying there is reason to believe that much of Cocotron's code was "inspired" by "outside sources." ;) > > After all the whole repository is online, and you may want to search for > yourself for unauthorized copies: > > https://github.com/cjwl/cocotron > > Best regards > > Rolf > > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > I apologize for voicing some of my bile with respect to Cocotron, but I believe our efforts would have been better consolidated than apart. Nevertheless, it's all open source and free software, so there's no problem. Just let it be known that I don't like the idea of any other project taking GNUstep code, relicensing it and claiming it as their own. GC -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
