Announcing the official launch of the "Free Pascal and Lazarus foundation" .

Announcing the official launch of the "Free Pascal and Lazarus foundation" .
http://foundation.freepascal.org/
The foundation is registered officially as a non profit organisation dedicated to the promotion and sponsoring of the open source Free Pascal and Lazarus project.
The Foundation site is hosted on the official freepascal.org domain, and the founding members include FPC members, me and Detlef the Edior of the "Blaise Pascal Magazine".
The foundation was established a while ago after discussions with members of the FPC community as a way to help fund the development and the promotion of the FPC and Lazarus.
We registered it with the hope that the Delphi will do well, and we will not have to launch publicly. However the events of the last few days, have led us to believe that now it is really needed, to ensure that the spirit of Delphi will survive.
I have also created G+ and FB pages for the foundation.
Please join and participate in the conversation and deciding how the foundation should be structured and operate, and what development should be funded, as well as how best to promote FPC/Lazarus.
https://plus.google.com/u/0/communities/116374648869450758662
https://www.facebook.com/groups/254527921579580/
http://foundation.freepascal.org

Comments

  1. this /sub thing is especially stupid when there are no other comments but /sub

    ReplyDelete
  2. Sergey Kasandrov /PleaseGoogleNotifyMeWhenRealComment :)

    ReplyDelete
  3. I still wonder why we haven't seen any comments from Embarcadero / Idera. Maybe due to the weekend?
    Good idea this foundation.

    ReplyDelete
  4. Thomas Mueller
    No weekend...
    I think they can not say anything positive.

    ReplyDelete
  5. How about starting a Patreon site? (And yes there are programmers too ;) )
    https://www.patreon.com/

    ReplyDelete
  6. Interesting: a private G+ community to promote things.

    ReplyDelete
  7. Jeroen Wiert Pluimers
    I think that was simply a [configuration] mistake when setting up the new G+ community page.

    ReplyDelete
  8. Graeme Geldenhuys I surely hope so. Boian Mitov why is it private?

    ReplyDelete
  9. I noticed the PDF project, if it's not already started, I suggest to start with SynPDF (http://synopse.info/fossil/wiki?name=PDF+Engine), which is Licensed under a MPL/GPL/LGPL tri-license.

    ReplyDelete
  10. Edwin Yip The PDF project is near completion, and most of the code is already added to the FPC Trunk repository. I did the work, and it was based on the PDF code found in the fpGUI Toolkit project, which in turn was a clean from-the-ground-up implementation. We reviewed a lot of existing Object Pascal based PDF libraries and most of them are flawed in the sense that they require GUI units to work (eg: SynPDF requires VCL to function, and isn't cross-platform last time I checked). That was a show-stopper for us (my client which commissioned the work), as they required a PDF engine that can run on a true headless server. The PDF code is released under the same license as the Free Pascal's RTL (with the static linking exception).

    ReplyDelete
  11. Jeroen Wiert Pluimers This seems to be a criticism to me :-) . I did the community. I thought it is better to be private for the dedicated people to join and share ideas. We can do another public one, but I believe the community is not the tool to promote, but a collaboration tool for the people that join, to discuss how the foundation should be structured, function, and what it should fund etc. This type of conversations are probably better being in a private Community IMHO ;-)

    ReplyDelete
  12. Javier Hernández Yes, delay loading and dynamic packages, are all things that I personally will push for. Things like this missing in Lazarus was the main reason for creating the Foundation...

    ReplyDelete
  13. Boian Mitov I've heard the word "achterkamertjespolitiek" a bit too often lately.

    ReplyDelete
  14. Jeroen Wiert Pluimers Except, nobody stops you from entering this one :-D . I just think it will be better without a bunch of spammers, and noise generators ;-)

    ReplyDelete
  15. Dammit, Sergey Kasandrov​ already used the old complaining-about-subs-as-a-sub gambit. Oh well, guess I'll have to settle for the old pointing-out-the-sub-gambit-as-a-sub gambit. ;-)

    ReplyDelete
  16. Graeme Geldenhuys Yes, SynPdf is tied to Windows, but extracting Windows dependency may have been easier to do. SynCommons is already compatible with a lot of FPC targets (including ARM) - and it is the only dependency of SynPdf. I don't blame the NIH syndrome: I caught it myself! ;)
    Just that there is so much to do, that Open Source may benefit for forks instead of from scratch working. Do you know Arabic? or Chinese? I don't, but some SynPDF users did help a lot, and already provide commits and fixes to extend the library beyond what I did ever imagine...

    ReplyDelete
  17. A. Bouchez I minor clarification of my previous post. The PDF generator code in fpGUI Toolkit was written some 6+ years ago (not by me). So it wasn't a brand new roll-your-own library situation (though I normally don't mind those). It had the best features and least dependencies, but most of it was with French identifiers. We started using it, translating it to English identifiers and in the process reworked quite a lot of code and classes in the process to improve the overall design.

    As for SynPDF's dependencies.... Windows-only (using Win32 API calls) was only part of the problem. SynPDF (like so many other Delphi based libraries) also depend heavy on the VCL. In the case of SynPDF, that is the Graphics unit, which in turn forces a GUI environment.  Some other libraries even depend on Forms and the Dialogs units too - crazy! But then, they normally only target Windows, and you don't get a true headless Windows environment. When it comes to generating a PDF document, it really shouldn't have any GUI requirements at all. That's what I accomplished with fpPDF. The same holds true for a reporting engine (again all Delphi reporting solutions require a GUI dependency - useless in a headless server environment). Soon the fpReport reporting engine (written from scratch) will be added to the Free Pascal repository too. :)

    The PDF code from the fpGUI Toolkit project was already FPC compatible and supporting Windows, Linux, FreeBSD, Solaris, RaspberryPi and many others. The code was much cleaner to start with, and we had full control over the code.

    I also have to add that the 1000+ pages of official PDF Specifications are sometimes hard to understand. So in a few cases I did browse other open source PDF library code to get a better understanding of a problem. So other open source PDF libraries (even ones written in PHP and Java) did come in handy at times.

    > provide commits and fixes to extend the library beyond
    > what I did ever imagine

    I know that feeling all to well. I author many open source projects (tiOPF, fpGUI, OnGuard (FPC port), FPTest (DUnit2 fork) etc). I have had some amazing contributions, especially in fpGUI and tiOPF.

    ReplyDelete
  18. >again all Delphi reporting solutions require a GUI dependency

    Not all.

    ReplyDelete
  19. Alexander Sviridenkov Okay, "all" is probably an over exaggeration, but I looked at about 7 delphi reporting products, all required a GUI dependency. eg: FastReport, ReportBuilder, RaveReports, ReportMan, etc.

    ReplyDelete
  20. +Boian Mitov I think the group should be public, all after all, it's discussion about public open source projects, why not? Sometimes people with something benefit would not even care to join and wait. Why worry about spammers if they couldn't post anything without joining the group.

    ReplyDelete
  21. Edwin Yip Well... we will need to make a new one then. G+ Does not allow private groups to be turned into public :-(
    But if the consensus is that it should be public, I will make a new one...
    And then again, I am creating it, but it is not my group. I am only one of the 3 founding members, just more invested in social media than the others, so handling this aspect for now:
    http://foundation.freepascal.org/about

    ReplyDelete
  22. RReposting my comment originally posted in the planed foundation *private group*:
    "Boian Mitov Actually, I doubt that such a foundation would work - you are not Mozilla Foundation or Apace Foundation. Other than a vague vision for a foundation, I would support crow-funding with very explicit features to implement. Example from the web: (https://www.indiegogo.com/projects/open-source-physics-engine-for-real-time-fluid#/) I'l give another example - the bergsoft.net owner would start a campain to port their simple yet useful controls to FPC with Mac OS support, etc, on indiegogo or another similar crowfunding site, I would support him, something like pre-pay $50 to pre-order the license. All delphi component vendors should consider my idea ;)"

    ReplyDelete
  23. Graeme Geldenhuys Does make sense!
    Where could we see the code?
    But there is always some API calls needed, e.g. for palette rendering, font sub-sampling, bitmap or metafile rendering. My guess is that 95% of the SynPdf code is already untied to the OS (if you disable UniScribe and TMetaFile support) and the graphics.pas reference could easily be avoided.

    ReplyDelete
  24. A. Bouchez
    The fpPDF and fpTTF code has already been released as part of the FPC Trunk repository in the packages directory (also known as FCL). [http://www.freepascal.org/develop.var]

    The fpReport code will be released in a few weeks time - also as part of Free Pascal's FCL components.

    The PDF and Report Engine do not require platform specific API calls or GUI dependencies. eg: We implemented fpTTF to extract font glyph metric information when needed - directly from the TTF or OTF font files. Other reporting solutions use Win32 API calls or pull in VCL to get to a Canvas class (yuck to both options), but they clearly don't have a drive to be truly cross-platform or simply lack the experience of developing for cross-platform. For fpPDF's image support we promote the usage of PNG (just like W3C does for the web) via FPImage (standard with FPC and again pure Pascal code). For other functionality, use separate units which would not force the core code to have GUI dependencies. eg: for fpReport we have separate units for generating PDF output and PNG output (via AggPas). Both are optional and others can be added over time, but the core fpReport engine always stay non-GUI and OS independent.

    ReplyDelete
  25. Graeme Geldenhuys Nice approach - clearly matching the FPC expectations!
    But you still lack of font-subset embedding, UniScribe and/or RTL support, encryption and optimized PDF generation size. To name a few.

    ReplyDelete
  26. A. Bouchez All in due time. Font-Subset Embedding is next on fpPDF's todo list. Any way of reducing the PDF size is a high priority item for my client. At the moment I'm completing some fpReport features, then I'll jump back onto the outstanding fpPDF features.

    ReplyDelete
  27. Jeroen Wiert Pluimers Now you can vote in the Community if it should be kept private, and/or if we need a public one :-) Please join and vote!

    ReplyDelete

Post a Comment