Removal of PDF functionality in 5.0

[PhilTaylor (aka PrazGod)]

http://mamboserver.com/cat/Developer_Blog/
Written by Robert Castley
Monday, 04 October 2004

The decision has been made to withdraw all PDF functions from Mambo 4.5.2.

This decision has not been made lightly but has been made for the following reasons.

* As anyone who has investigated the automated PDF Generation process, creating PDFs from dynamic code is not the most simplest of tasks. Especially if the page to be converted contains invalid or non standard HTML or images, and even harder is if the page is rendered with tableless CSS designs (which are becoming more common).

* The PDF Generation in Mambo 4.5 was only ever text only, and worked really well as the output from Mambo into the template was based on tables and CSS styles only. An unsupported function in the code also supported the creation of PDFs with images if, and only if, HTMLDoc was already installed on the server.

* With the amazing advances of Mambo 4.5.1a - 4.5.2 it has been increasingly difficult to provide a system that would create great looking PDFs from Mambo content. Also, with the move to more DIV and tableless designs means that the majority of new template designs render incorrectly in auto-generated PDF's.


We like to only implement the very best technology into Mambo core - and for the above reason we do not consider PDF generation to be performing to the standard we would like - therefore the decision to remove it has been made.

This does not mean it has gone forever, but until we can find or be notified of a more suitable PDF Generation engine this is the current status.

[ennsol]

Is there going to be - or any chance of - a commercial solution in the interim?
Regards
Mark

[spacemonkey]

We should be able to separate the content from the modules - if this were possible (regardless of template used) then we could then output the document to PDF.

The current problem stems from the use of DIVs instead of TABLEs to place modules within the content area, correct? If we could parse out just the actual content, then this would no longer be an issue.

The only possible hitch in this approach is templates using DIVs to place modules within the content, and a module's output needing to be in the PDF as well.

There's my quick poorly-researched knee-jerk thought of the day ;)

[PhilTaylor (aka PrazGod)]

There is not really a commercial solution that is workable either!

My thought, in my role as a custom developer, is to have a different template version totally for just the PDF. But this would need a bit more thinking about and we want to progress with Mambo 4.5.2 so I have placed it to one side for now.

HTMLDoc is really the only solution that handles the complete conversion of a HTML Page to a PDF dynamically and on the fly with "reasonable" layout results. But it relies heavily on correct HTML and table-rich designs

Like the announcement said - we have not stopped with the idea of providing PDF Support - just we have stopped the current way

[idigital]

Mightn't it still be a good idea to keep in legacy support for those who are using solely table based layouts? Or is it a problem with the new core layout?

Seems like a big feature to drop.

Cheers,

Damian

[mmx]

Most of the newer platforms in other languages seem to be moving toward storing all content in XML and performing XSLT transformations from XML to XHTML, PDF, DOC, etc to the textarea form elements. So they are basically single sourcing the content to multiple formats.

The big hangup on doing this for Mambo is the editor associated with the textarea elements. We support a lot of these. Separate filters would need to exist for each editor to preprocess the content before performing an XSLT to XML. If we could simulate something like the action chains used in MVC, Cocoon, or Maverick with a series of filter-like plugins, it might be possible to solve the problem. I'm basically talking about creasting the equivalent of action chains using a series of plugins that would handle bidirectional transformations.

Talk to Tim Broeker about this and ask him if he thinks DOMiT/Saxy could handle the XSLT transformations.

[aquebahamas]

Phil, is it possible for you to post a sticky under this 4.5.2 thread to always remind us of the road map with out having to jump to mamboforge.

You can always copy and past to update it.

The reason i ask is i did not want to install a program on my system just to read one file every 60+ days. Keeps a clean system for me.

[PhilTaylor (aka PrazGod)]

The very latest version of the roadmap in html form is always available at

http://www.phil-taylor.com/component/option,com_wrapper/Itemid,78/

this page is dynamically updated with the roadmap from the CVS version. You will not need to download any application to read it as its in HTML format.

[idigital]

Hmmm, I must be invisible or something. :|

See above post.

Cheers,

Damian

[alterego]

While I thought the 'feature' was a plus in Mambo's favor as a CMS, not many are actually using the feature, as far as I can tell. I tried it myself, but as a Mac user, it was cleaner to just print directly to PDF from the print-friendly view. And there are better open source addons to Windows as well, which give similar capabilities to Windows as we have in Mac OS X for creating PDFs from any document.

[Fuga]

i think this is a good step
the pdf export not support all language like arabic and any rtl language

you can use word export or html export for saving the content ( it will be support all language )

thanks

[mmx]

Phil... is it possible to setup the existing interface to display the button conditionally based on the setting of a hidden $mosConfig_ parameter (include the parameter in configuration.php set to 0 without displaying it in Global Configuration) unless a pdf.class.php exists in includes/. Then allow the pdf.class.php to handle redirection (if it exists) to a component for generating the pdf and displaying it in a popup. Otherwise, provide the pdf.class.php with some stump functions for generating and rendering.

There are a lot of other solutions for generating a ps file and converting to pdf format, many of which have not been tried yet (Ghostscript, Open-JADE, YAPS, etc.). This puts the burden on third-party developers. I believe that this is the solution used in TYPO3 to handle this sort of thing because of the numerous ways it could be handled with various platforms.

[spignataro]

http://www.fpdf.org


this is a great solution and im prolly going to be using it later in the future....

[gsownsby]

I think it is important that Mambo maintain the capability to create PDF output either through a component or module approach. If one doesn't need it or doesn't choose to use it, that's fine but at least maintain the capability.

In the commercial world, PDFs are very useful and help to minimize problems with content printing and to some degree, secure a document from changes. This capability was one of the features that was very attractive to my company as we explored various CMS applications.

Just the opinion of 30+ years in the IS world...thanks.

[kabam]

I agree with gsownsby. While pdf creation was not the only factor, it was one of the "hey, this deserves a better look" features that drove me to mambo in the first place. I must admit however, that I was disappointed that it didn't seen to work with the images and such. If pdf creation is dropped from the core, I would love to see a third party module or component that handled pdf creation with images.

[tonyskyday]

I think it is important that Mambo maintain the capability to create PDF output either through a component or module approach. If one doesn't need it or doesn't choose to use it, that's fine but at least maintain the capability.

In the commercial world, PDFs are very useful and help to minimize problems with content printing and to some degree, secure a document from changes. This capability was one of the features that was very attractive to my company as we explored various CMS applications.

Just the opinion of 30+ years in the IS world...thanks.

Just for clarity, you would prefer poor pdf rendering to no pdf rendering?

I just want to second the request to provide the "hook" for third-party developers to include pdf functionality and have it be as seamless as the current solution (the pdf button).

[mmx]

Just for clarity, you would prefer poor pdf rendering to no pdf rendering?

I just want to second the request to provide the "hook" for third-party developers to include pdf functionality and have it be as seamless as the current solution (the pdf button).
Actually... this is probably the better solution because one could take what is already there and convert it into a plugin and make the selection of PDF processing optional as it now is for editors. So what's there now could be the default solution and the users could make a selection from Global Config to use a different mambot. Otherwise, the default could be nothing and would stay nothing until the user installed a mambot. This covers all the bases, including the creation of mambots that could interface with commercial solutions from Adobe and other vendors (more of an option for OSX and Windows users who maintain their own servers but still an option).

[tonyskyday]

Actually... this is probably the better solution because one could take what is already there and convert it into a plugin and make the selection of PDF processing optional as it now is for editors. So what's there now could be the default solution and the users could make a selection from Global Config to use a different mambot. Otherwise, the default could be nothing and would stay nothing until the user installed a mambot. This covers all the bases, including the creation of mambots that could interface with commercial solutions from Adobe and other vendors (more of an option for OSX and Windows users who maintain their own servers but still an option).

And print and email buttons could also be mambots, allowing for integration and customization of those as well.

[mambovince]

Will too many of these MamBots cause other issues - page loading speed?

Vince

[tonyskyday]

Will too many of these MamBots cause other issues - page loading speed?

Vince

The new mambot controller lets you turn things on and off at will. Also, I'm not sure it would be any more code than required to load the current print/email/pdf functionality. It's worth testing, though.

[PhilTaylor (aka PrazGod)]

For tha mambo core we have to provide "simplicity" and the ability to support different platforms and configurations of server.

Mambo prides itsself on requiring any "additional" 3rd party applications to be installed on servers to work - even the very basic hosting accounts normally have at least the minimum "stuff" to allow mambo to run.

PDF Generation With inline images, from an HTML source, for anyone who really hasnt done thier homework well, is difficult almost, impossible without additional products installed on the server. with invalid html or div based pages this task becomes almost impossible.

I was the developer who first introduced PDF to Mambo core, and I have also been the person resposible for the decision to remove it.

There are solutions, for those people who can install HTMLDoc on thier server, or have root server access or have advanced linux/web knowledge, however mambo core has to support the majority of platforms, we have not included, up to now, anything that only works in "certain" conditions (Apart from SEF Urls but that is really important feature!)

The original PDF for Mambo 4.5.1a file is still available at http://www.phil-taylor.com but for Mambo 4.5.2 all PDF Support has been withdrawn

In the future, when we have the mambot system running at full speed I will probably release a FREE port of the existing Mambo 4.5.1 PDF systems as a mambot for Mambo 4.5.2, however we need to see where Mambo ends up in the next few months.

[tonyskyday]

One feature I'd like to see in a new third-party pdf feature, is the ability to define a specific pdf for certain pages, so that you knwo it looks just like you want (that is, a fixed pdf, rather than a dynamically generated one).

[PhilTaylor (aka PrazGod)]

Phil... is it possible to setup the existing interface to display the button conditionally based on the setting of a hidden $mosConfig_ parameter (include the parameter in configuration.php set to 0 without displaying it in Global Configuration) unless a pdf.class.php exists in includes/. Then allow the pdf.class.php to handle redirection (if it exists) to a component for generating the pdf and displaying it in a popup. Otherwise, provide the pdf.class.php with some stump functions for generating and rendering.

There are a lot of other solutions for generating a ps file and converting to pdf format, many of which have not been tried yet (Ghostscript, Open-JADE, YAPS, etc.). This puts the burden on third-party developers. I believe that this is the solution used in TYPO3 to handle this sort of thing because of the numerous ways it could be handled with various platforms.

The Mambo 4.5.1 way did provide a configuration var and an implementation per content item.

I will investigate the TYPO3 way of doing PDF on my return from the Linuxworld Expo, there maybe a way that we can write a class that looks for all the "dependant" software and uses it if found, and try to support as many solutions as possible -but unless a solution performs well, ie gives great looking colourful and images PDF then it will not change the decision to withdraw PDF Support

Only the best is good enough for mambo core

[PhilTaylor (aka PrazGod)]

http://www.fpdf.org


this is a great solution and im prolly going to be using it later in the future....

This class was the basis of the original PDF Support in Mambo 4.5.1 :-) however it doesnt support the dynamic inclusion of inline images, they can only be programically placed

[PhilTaylor (aka PrazGod)]

One feature I'd like to see in a new third-party pdf feature, is the ability to define a specific pdf for certain pages, so that you knwo it looks just like you want (that is, a fixed pdf, rather than a dynamically generated one).


Im one step ahead :-)

how about being able to attach documents to content records? Attach a PDF, or any other file. These files being manually created, uploaded and attached to content

seams like a generic solution that would enhance mambo

[mambovince]

how about being able to attach documents to content records? Attach a PDF, or any other file. These files being manually created, uploaded and attached to content
I thought this was already possible Phil, is it the DocMan add-on to insert a doc/file link anywhere?
Vince

[PhilTaylor (aka PrazGod)]

Sure probably is with a third party component - but im thinking more about the core of mambo :-)

I will be talking to robert tomorrow about maybe having a few more fields in mos_content

things that might be helpful for some sites, we already have hidden fields that we are not utilising to the full - like urls

So im thinking:
- source publication
- link to article (link to external webpage)
- link to author details page (now possible with new contacts manager)
etc....

[PhilTaylor (aka PrazGod)]

all those options would be controlled by parameters and you would be able to hide/turn off :-)

[stingrey]

ll those options would be controlled by parameters and you would be able to hide/turn off Look slike you've got the param bug :lol:

[mmx]

If Mambo knew what resources were available on a webserver, then some conditional decision making becomes possible. Some hosts might have applications like Ghostscript, HTMLdoc, ImageMagick, etc. installed as shareable resources. Mambo has no idea if these are installed or where they are located.

If you add something like an Advanced form to System and listed these items with Yes/No lists, then the user could identify what was installed on their server based on feedback from their host. The missing ingredient is knowing the path and possibly the executable for those resources, so a varchar(255) could be provided for defining the absolute path to those resources. Actually, this could be a standalone component.

Or can you mimic the above using the plugin approach.

In the case of pdf, you could probably make CMTs more aware of available resources based on the state of those settings and conditionally use something like HTMLdoc or Ghostscript if it they were available.

[idigital]

Only the best is good enough for mambo core


Does that mean you'll be getting rid of the Media Manager then? Because that thing is a butt-ugly old dinosaur, that's bad for 56k users and not very functional.

Although I guess someone could create a better 3rd party solution. 8)

Cheers,

Damian

[PhilTaylor (aka PrazGod)]

Damian,

Any media manager will be a problem for 56k users! Quite frankly the internet has moved on and most images now are larger and not suitable for users on a 56k modem.

Any media manager that is functional will involve displaying the images and media it controls - this means it will always be a problem with slow connections!

So my basic answer is no.

Phil.

[idigital]

Any media manager will be a problem for 56k users! Quite frankly the internet has moved on and most images now are larger and not suitable for users on a 56k modem.

Of course, this problem could be much reduced with a simple GD thumbnail of the images in the Media Manager. :roll:

Any media manager that is functional will involve displaying the images and media it controls - this means it will always be a problem with slow connections!

There are many ways in which the media manager could be improved, as has been discussed on these forums. :-|

So my basic answer is no.

What's your advanced answer then?

Cheers,

Damian

[Gayle]

Quite frankly the internet has moved on and most images now are larger and not suitable for users on a 56k modem.
I'd dispute this quite strongly. The majority of internet users are still on 56k. In the UK only 1 in 3 have access to a broadband connection (I believe this figure includes businesses) and in the US 51.39% (according to Nielsen/Netratings) of home users are still on 56k or less.

Broadband is still the future for many of us, I won't even have the option for another year!

[PhilTaylor (aka PrazGod)]

<flame>


Yeah, it's very cool indeed for us 56kers ;P

LOL - Says it all


Of course, this problem could be much reduced with a simple GD thumbnail of the images in the Media Manager. :roll:

Mambo prides itself on NOT requiring anything other than PHP/Mysql and a webserver. Many hosting accounts still dont come with GD installed (believe it or not!) and therefore we would be providing a system of no use to many users.

I agree that we could use GD (If available) to make thumbnails - however we would also need to provide a "norm" that doesnt rely on GD.

I also believe that there are more important things to do with Mambo in the next versions than to worry about the Media Manager. Things like greater ACL and language handling.

If you, or another developer, provides a better system I am sure that it would be considered for the core by Robert and the team, however the core team have its eyes elsewhere, and quite rightly so, concentrating on the items on the official roadmap.


There are many ways in which the media manager could be improved, as has been discussed on these forums. :-|

Sure, there are also better ways for people to get involved that have also been talked about - but no one ever submits any code or ideas! (And if they do its at the wrong time!)

For example we asked for people to test Mambo 4.5.1 CVS for two weeks before the release, an hourly cvs was made available in zip format, we asked repeatly for people to report bugs and issues BEFORE we made an official release. The bug tracker was at zero bugs for many days before we made the official release. Today there are over 30 open issues! Why on earth people didnt report these before when we asked for it


And why do you call yourself a developer, and then complain about the "object bug" when the fix was a simple change to lines of code - less than TWO chars had to be changed!!!!!! one on each line!!! and then you complain that it took the core devs more than a day to fix your major issue! - Gesh!

You bump posts which you made less than 45 mins ago!
http://forum.mamboserver.com/showthread.php?t=18119

Some quotes of yours...

Ah, I can't wait until I've finished this project I'm working on, it's time for some 3rd party components to replace core components I think. The media manager could do with a long overdue revamp

Well we cant wait for your positive contribution of code either!

Mightn't it still be a good idea to keep in legacy support for those who are using solely table based layouts?

So you want use to support legacy stuff in mambo for all of the future - gesh - so much for progress! I bet you want us to bring back the admin interface for mambo with the pink girly colours too!

We, the core team, are trying to move mambo forward - You, iDigital are holding us back, distracting us, and using up our valuable time that could be better used. This will be personally my last direct reply to you. All your posts will be ignoired from now on by me I know that others feel the same way after hearing people talk about YOU at the LinuxWorld Expo yesterday in London - people, real people, face to face telling me what they think of you!


I didn't even have to get out the dreaded trout! :-D


And you wonder why you are not liked?


I'd hardly call an open source release competition for a commercial release


So Why is Mambo (Open Source) more popular than Mambo CMS (Miro) ?????
So why is Linux (Open Source) so popular compared to other Operating systems?????


Not meaning to be rude,


really?


Phil, great idea for a component. Have you considered making available some kind of free upgradable component, or a cut down freely available version? It might sound wacky, ...

(Regarding mosDirectory)
No. Not at all. Do you see WindowsXPLite for free? mosDirectory has not yet even been completed and over 150 people have already purchased it - why should i give it away for free when its already so popular. I have no problem in selling my solutions - currently I make 100% of my income from Mambo components!, and I own my own house, drive a jaguar XJ6 car and Im preparing for marriage - all on my profits - so

It is wacky - supporting free components is a lot of hard work! My contribution to Open Source and to FREEness is MAMBO CORE! - That is appreciated by a lot of people, I only have 24 hours in a day, therefore the quality programming time I have I give FOR FREE to Mambo CORE and the rest of my time I give to Commercial components - There was even a day before Mambo 4.5.1 was released when I spent 34hours on bug fixing and reducing the bug tracker to zero bugs in one day (With the help of the rest of the team - it was a team effort!) - so dont go on and on about me charging for my hard work - you are already benefiting from my FREE work by using Mambo core! Gesh.


Phil, I thought we'd put all of this behind us. I don't post on the official forums to be hassled by anyone, I post here because I am a serious and dedicated developer.


I believe this statement is a load of nonsense! - a quick search of all your old postings proves this NOT to be the case!

There's so much that could be reworked in 4.5.1 to make an even better 4.5.1

Well thats helpful! Man you are never satisfied!!!!!

Its all about lets bully the core team until THEY do what WE want. Rather than "How can I best help" the core team.




What's your advanced answer then?


Well I guess this is my answer to you, Damian, As I have already said I will be ignoiring ALL your posts from now on.

</flame>

[Gayle]

Interestingly, the top result in Google for the search term 'php print pdf' is a thread on these forums :)

http://forum.mamboserver.com/showthread.php?t=7918

[PhilTaylor (aka PrazGod)]

I'd dispute this quite strongly. The majority of internet users are still on 56k. In the UK only 1 in 3 have access to a broadband connection (I believe this figure includes businesses) and in the US 51.39% (according to Nielsen/Netratings) of home users are still on 56k or less.

Broadband is still the future for many of us, I won't even have the option for another year!


I agree that the majority of users are still on 56k :-)


Despite higher growth rates for broadband, there are nearly twice as many narrowband users as broadband users in the U.S. In comparison, last year there were three times as many narrowband users as broadband users. Narrowband users continue to outweigh broadband users with 69.6 million users.
taken from: http://www.internetworldstats.com/articles/art030.htm

[Gayle]

After a little thought and Googling, if I were doing this for myself I'd probably use html2ps to generate a postscript file then run it through ghostscript and output the resulting PDF. However, that introduces dependencies on Perl, html2ps, and Ghostscript (which needs CUPS I believe). While Perl may be expected to be found on a webserver and installing html2ps is not a problem, Ghostscript/CUPS are not common features of a webserver so while it's an almost perfect answer for users with control over the server, Joe Random User still can't use it.

[idigital]

<flame>

Ok, you obviously know what you're doing, Phil. Bit bloody unnecessary as I wasn't actually flaming you, but here we go. :-|

Mambo prides itself on NOT requiring anything other than PHP/Mysql and a webserver. Many hosting accounts still dont come with GD installed (believe it or not!) and therefore we would be providing a system of no use to many users.

A system to check whether such vital extensions are installed has been talked about on these forums recently. It could be as easy as not having the thumbnailing feature enabled by default, and the user being able to select whether they'd like to use it. There could be the option of other similar extensions like Image Magick as well.

I agree that we could use GD (If available) to make thumbnails - however we would also need to provide a "norm" that doesnt rely on GD.

No need to flame me then, is there.

I also believe that there are more important things to do with Mambo in the next versions than to worry about the Media Manager. Things like greater ACL and language handling.

Well, I know I'm not the only one who thinks the Media Manager could be improved upon. It really does look out of place in 4.5.1.

If you, or another developer, provides a better system I am sure that it would be considered for the core by Robert and the team, however the core team have its eyes elsewhere, and quite rightly so, concentrating on the items on the official roadmap.

Phil, I'm pretty sure that anything I created would definitely not be considered for the core by Robert, nor would I want it to be.

Flames like yours only reinforce that feeling.

Sure, there are also better ways for people to get involved that have also been talked about - but no one ever submits any code or ideas! (And if they do its at the wrong time!)

Oh boo bloody hoo. Plenty of ideas are submitted, the reason you probably don't get many code submissions for the core is because this is not actually encouraged.

And what time is the wrong time btw? Possibly now has been the wrong time for me to bring this up, given your reaction.

For example we asked for people to test Mambo 4.5.1 CVS for two weeks before the release, an hourly cvs was made available in zip format, we asked repeatly for people to report bugs and issues BEFORE we made an official release. The bug tracker was at zero bugs for many days before we made the official release. Today there are over 30 open issues! Why on earth people didnt report these before when we asked for it

Phil, as you know, I was one of the people who did do some testing on the 4.5.1 CVS and I did find bugs and submit them.

Why on earth don't you guys do some bug testing yourselves? Jeez. :roll:

And why do you call yourself a developer, and then complain about the "object bug" when the fix was a simple change to lines of code - less than TWO chars had to be changed!!!!!! one on each line!!! and then you complain that it took the core devs more than a day to fix your major issue! - Gesh!

Phil, I really don't know why you are so wound up right now. I did not complain about the "object bug", I posted about it and discussed it and submitted it to the bug tracker. Then I thanked you for a job well done.

In fact, I just posted to you before how good it was that you setup that HTML roadmap.

Roadmap in PDF format (http://forum.mamboserver.com/showthread.php?t=17712)

So quit this "idigital bashing" once and for all will ya? Gawd. :-|

You bump posts which you made less than 45 mins ago!
http://forum.mamboserver.com/showthread.php?t=18119


Yes Phil, I am aware of my posts you know. It was an important issue at the time, as I explained. And it was resolved. :-?


Some quotes of yours...

This is getting incredibly petty.

Well we cant wait for your positive contribution of code either!

WTF? Should I be under any pressure to contribute code as a 3rd party developer? I don't think so.

This kind of **** has almost pushed me into leaving the community before, now I can see it is just a matter of some people with short fuses taking their frustrations out on an easy target.

I thought we'd all moved past this. :-|

So you want use to support legacy stuff in mambo for all of the future - gesh - so much for progress! I bet you want us to bring back the admin interface for mambo with the pink girly colours too!

Phil, I'm not the only one that would like to see legacy support in Mambo.

As for the admin interface, I have my own plans for that which you will be able to read all about once I have time to release Backenders.

We, the core team, are trying to move mambo forward - You, iDigital are holding us back, distracting us, and using up our valuable time that could be better used. This will be personally my last direct reply to you. All your posts will be ignoired from now on by me I know that others feel the same way after hearing people talk about YOU at the LinuxWorld Expo yesterday in London - people, real people, face to face telling me what they think of you!

You what?!?!?

I'm holding back the project? Gawd phil, what are you smoking man?

I'm a dedicated Mambo developer, if I wasn't I wouldn't still be here after all this time. I hate to bring it up again, but I would have taken Robert's advice and found another community.

I happen to believe in Mambo, and I have strong ties in the community. I've got plans for future development, and I'm a member of several projects and have an active one at the moment which has just attracted several developers as well.

Am I attacking you Phil? No.

And you wonder why you are not liked?

No, I don't wonder anything of the sort. I'm not that insecure.

I do have many friends in the Mambo community, if you choose not to be one of them, that's your choice. Just don't ever flame me like this again. :-|

So Why is Mambo (Open Source) more popular than Mambo CMS (Miro) ?????
So why is Linux (Open Source) so popular compared to other Operating systems?????

I really don't know what you're talking about here. As far as I'm concerned Mambo is the best CMS out there, and even you're current attitude doesn't change my opinion about that.

(Regarding mosDirectory)
No. Not at all. Do you see WindowsXPLite for free? mosDirectory has not yet even been completed and over 150 people have already purchased it - why should i give it away for free when its already so popular. I have no problem in selling my solutions - currently I make 100% of my income from Mambo components!, and I own my own house, drive a jaguar XJ6 car and Im preparing for marriage - all on my profits - so

I believe you already answered that post, Phil. If you have any serious issues with me, please take them up via email and not in a public forum. It doesn't do you or Mambo any good to be seen acting like this in public.

It is wacky - supporting free components is a lot of hard work! My contribution to Open Source and to FREEness is MAMBO CORE! - That is appreciated by a lot of people, I only have 24 hours in a day, therefore the quality programming time I have I give FOR FREE to Mambo CORE and the rest of my time I give to Commercial components - There was even a day before Mambo 4.5.1 was released when I spent 34hours on bug fixing and reducing the bug tracker to zero bugs in one day (With the help of the rest of the team - it was a team effort!) - so dont go on and on about me charging for my hard work - you are already benefiting from my FREE work by using Mambo core! Gesh.

Phil, I am not attacking you. If you wish to sell commercial components, so be it, I was just offering a chance for discussion about other alternatives.

Its all about lets bully the core team until THEY do what WE want. Rather than "How can I best help" the core team.

I'm not bullying anyone, Phil.

Take a look at your own post.

Well I guess this is my answer to you, Damian, As I have already said I will be ignoiring ALL your posts from now on.


I guess that'll make it easier for you not to apologise for this outburst of yours then.

Too bad.

Either way, I'm not going anywhere, I love Mambo and the Mambo community.

Cheers,

Damian

[PhilTaylor (aka PrazGod)]

I guess that'll make it easier for you not to apologise for this outburst of yours then.

I shall not apologise - even if that costs me my position and credibility in the Mambo community, or even my place amongst the core development team personally I stand behind my comments.

I shall not respond individually to your replies as I dont believe they were replies, rather just rebuttals.

I shall not flame you again - infact i cant even believe im writing this.

Its this simple, you are not part of the decision process for mambo - you hate that and therefore make the life of ALL mambo core developers, forum moderators, and community leaders hell - that is the simple truth.

Damian, quite frankly I believe you are not welcome in the mambo community. I searched these forums for someone who publically has said that they welcome your contribution and I never found one post. There may be some people that disagree with me - however I truly believe they are in the minority.

Now I am going back to working on Mambo 4.5.2 - see you are slowing the work!!!!

[PhilTaylor (aka PrazGod)]

After a little thought and Googling, if I were doing this for myself I'd probably use html2ps to generate a postscript file then run it through ghostscript and output the resulting PDF. However, that introduces dependencies on Perl, html2ps, and Ghostscript (which needs CUPS I believe). While Perl may be expected to be found on a webserver and installing html2ps is not a problem, Ghostscript/CUPS are not common features of a webserver so while it's an almost perfect answer for users with control over the server, Joe Random User still can't use it.

Sure there are ways of doing it with other dependancies - but as you have found there are many dependancies for these.

We could, and might, write a really huge pdf.php file that can check for the different dependancies and can generate a PDF at the end of it. (As Damian wants)

However there are so many different configurations that writing such a function would be complex with loads of IF THEN logic. We would therefore be writing 4-5times more code for little or no advantage for joe user.

Also without Tables in the html pdf generation will still be an issue - there really is no quick solutions to getting beautiful PDF output with colour and images!

As we said in the official announcment we did not take the decision lightly to remove PDF functionality :) I personally was sad to see the decision was made as it was me that first implemented PDF generation into mambo core - it was the first thing i did after becoming a core team member, thats why its such an emotive issue for me.

We, I, am open to suggestions on the best way forward - and we, I, would love to have a PDF function in mambo core. But we really must have a solution that is dependable and generates GREAT looking PDF's with images rather than text only with rubbish layouts.

Phil.

[idigital]

I shall not apologise - even if that costs me my position and credibility in the Mambo community, or even my place amongst the core development team personally I stand behind my comments.

Fair enough, if you feel justified in your behaviour then that is your perogative.

I shall not flame you again - infact i cant even believe im writing this.

What cause you to flame me this time is beyond me. Possibly you're under some kind of non-Mambo related stress, and I can understand this.

Its this simple, you are not part of the decision process for mambo - you hate that and therefore make the life of ALL mambo core developers, forum moderators, and community leaders hell - that is the simple truth.

If that's how you see it, Phil.

I think that everyone in the community is a part of the decision making process for Mambo, which is one of the great things about Open Source development.

As for making the life of ALL mambo core developers, forum moderators, and community leaders hell, that's frankly a ridiculous statement. I chat to several core developers outside of these forums, and am good friends with some moderators and even community leaders.

Just so that you know, I'm not justifying myself here, it's just disturbing that you have such a warped perception of me.

Damian, quite frankly I believe you are not welcome in the mambo community. I searched these forums for someone who publically has said that they welcome your contribution and I never found one post. There may be some people that disagree with me - however I truly believe they are in the minority.

There is more to this community than these forums, Phil, possibly if you were ever online with your MSN account you'd find that. Maybe you'd even find me less offensive if you actually had a live chat with me rather than misinterpereting my forum posts.

I know I'm welcome in this community, and I've made many friends here. You could notice from my signature that I'm also a member of a few other active projects. Really, I'm not going anywhere.

Also I don't think anyone deserves this kind of flaming for any reason.

Now I am going back to working on Mambo 4.5.2 - see you are slowing the work!!!!

Am I forcing you to waste your time flaming me? No.

Take it easy,

Damian

[PhilTaylor (aka PrazGod)]

possibly if you were ever online with your MSN account

I am online 24/7 - I just have your account blocked.

[Gayle]

Sure there are ways of doing it with other dependancies - but as you have found there are many dependancies for these.

We could, and might, write a really huge pdf.php file that can check for the different dependancies and can generate a PDF at the end of it. (As Damian wants)

However there are so many different configurations that writing such a function would be complex with loads of IF THEN logic. We would therefore be writing 4-5times more code for little or no advantage for joe user.

Also without Tables in the html pdf generation will still be an issue - there really is no quick solutions to getting beautiful PDF output with colour and images!
html2ps claims to be able to handle CSS, I might actually do some experimentation along these lines (you know how much I love doing that) and see what it looks like. I think I have an approach that could be usable as an addon at least (certainly not universal enough for the core, that would be hard as you say).
We, I, am open to suggestions on the best way forward - and we, I, would love to have a PDF function in mambo core. But we really must have a solution that is dependable and generates GREAT looking PDF's with images rather than text only with rubbish layouts.
That's yet another reason why you're part of the core team and I'm not. I can come up with a solution to a problem that works great for me, you guys come up with solutions that work great for EVERYONE which is much harder.

Just as an aside (may $deity strike me down for saying this) but I actually quite like Damian. There are times I wish he'd engage brain before putting mouth into gear (quite a lot of them) but he really does have some interesting and progressive ideas along with code to back them up. I wouldn't say it's core stuff but he really has some spangly proof of concept code especially on different interfaces. I guess it's the difference between just seeing him post here and chatting to him on IRC regularly.

[mmx]

Is there any reason why config could not include a parameter for specifying the url used as the media manager (index.php?option=com_whatever&task=manager). Then something like a gallery or a souped up version of docman could provide media manager like support on an user-defined basis.

Does that mean you'll be getting rid of the Media Manager then? Because that thing is a butt-ugly old dinosaur, that's bad for 56k users and not very functional.

Although I guess someone could create a better 3rd party solution. 8)

Cheers,

Damian

[spignataro]

cant we all just get along....sometimes things can possible be taking out of character. Lets cool down and move forward.

anyways folks....as for the suggestion of html2ps i have looked into it a while ago along with FPDF...but i find it possibly wont be feasable because not everyone has perl installed by default on servers. Most servers have php installed by default.

And as for inline images you need ImageMagick which i know a few servers dont have support for.

Just my 2cents.

Question? Could two functions be implmented into the pdf such as FPDF and then html2ps and god i forget the one that is already implemented. I know this would be alot of work and phil like you said alot of IF THEN statements.

Now the questions just comes down to....is it feasable? If not then move on to a new solution. Such as suppling differant packages that can be installed through the Components installer. (example would be how SEF Advance works through there now)

Which means we could use various differant PDF products and have the user choose there use of a product making it easier and simpler.

Again some more of my 2 cents

[idigital]

Is there any reason why config could not include a parameter for specifying the url used as the media manager (index.php?option=com_whatever&task=manager). Then something like a gallery or a souped up version of docman could provide media manager like support on an user-defined basis.

That's a clever way of doing it :)

I love parameters ;)

Cheers,

Damian

[tonyskyday]

I love parameters ;)

Did someone say "parameters"?

Where's Rey? He's the parameter guy, he'll be all over that like white on rice!
:mrgreen:

[Gayle]

anyways folks....as for the suggestion of html2ps i have looked into it a while ago along with FPDF...but i find it possibly wont be feasable because not everyone has perl installed by default on servers. Most servers have php installed by default.
Absolutely right (as Phil said as well). It will make for an interesting experiment though and possibly a solution for whatever subset of Mambers meet the requirements. Definitely not good enough for the core though.
Now the questions just comes down to....is it feasable? If not then move on to a new solution.
As it stands, I don't think direct PDF generation from PHP is a feasible option. You'd need to basically simulate a full HTML renderer which is just NOT going to happen. There is no pure PHP solution that doesn't suck in some way (YaPS is horrendously complex for anything beyond basic text and image placement) and as far as I can see anything will just be a kludge. Phil had it closest with HTMLdoc but that's not an option for most people, my honest opinion is that there is not and will not be a universally acceptable solution any time soon.

I think the future of PDF generation is gong to be a Mambot to insert the link and a component/addon to do the generation. That way you can have half a dozen different solutions available and people can pick the one that works for them.

Phil: This is just an idea but so much of what I tinker with these days is not really a component or a module but something almost external to the Mambo core. Maybe we should have an extensions directory for such things to go in instead of having them dotted here there and everywhere. External PDF solutions and XMLRPC addons are both examples of what I mean.

[PhilTaylor (aka PrazGod)]

Is there any reason why config could not include a parameter for specifying the url used as the media manager (index.php?option=com_whatever&task=manager). Then something like a gallery or a souped up version of docman could provide media manager like support on an user-defined basis.

If there were viable alternatives to the media manager then we could put a config var in the configuration to the name of the component to use in the menu manager link

var $MEDIAMANAGER = 'com_mediamanager';

or

var $MEDIAMANAGER = 'com_3rdPARTYmanager';

But i dont know of any 3rd party components that could completly replace the media manager yet - maybe i just have not looked enough :-)

[PhilTaylor (aka PrazGod)]

Phil: This is just an idea but so much of what I tinker with these days is not really a component or a module but something almost external to the Mambo core. Maybe we should have an extensions directory for such things to go in instead of having them dotted here there and everywhere. External PDF solutions and XMLRPC addons are both examples of what I mean.

I know where you are going with this - although there are not maany "external" things to really warrent it at the moment (in my opinion) although in the future i really believe that we will need this.

XML-RPC by the way will be/is a webservices component (Although thats where Andrew is heading) but all that is still up in the air so will probably change (Especially if roberts ideas get implemented)

[mmx]

But i dont know of any 3rd party components that could completly replace the media manager yet - maybe i just have not looked enough :-)
I think there would be if the door was opened to make it possible. This is nothing new and fits in well with core team ideas implemented elsewhere in Mambo.

[Gayle]

I know where you are going with this - although there are not maany "external" things to really warrent it at the moment (in my opinion) although in the future i really believe that we will need this.
You're right, at the moment it's hardly critical but in years to come I think it will become more of an issue.

[PhilTaylor (aka PrazGod)]

I think there would be if the door was opened to make it possible. This is nothing new and fits in well with core team ideas implemented elsewhere in Mambo.

They can be made as components :-) :-)

[PhilTaylor (aka PrazGod)]

You're right, at the moment it's hardly critical but in years to come I think it will become more of an issue.

It will :-) but eventually CMTMs will be come "elements" and then you will be able to have External elements :-) *but thats a while away yet :-)

[mmx]

Andrew discussed this earlier during the 4.6 prototype development cycle with reference to it as a possible part of the package concept. That is, taking the shared/ directory concept from 5.0, expanding on the idea, and using it to store third-party libraries and scripts that could be reused among the various packages.

Some of the original reasons for this already have been fullfilled by the plugin architecture. In fact, Mambo is much more extensible than most people realize because of plugins. I don't think the full power of plugins has sunk in yet.

Much earlier, Gayle suggested a similar idea with reference to automatically appending classes to Mambo.

I know where you are going with this - although there are not maany "external" things to really warrent it at the moment (in my opinion) although in the future i really believe that we will need this.

XML-RPC by the way will be/is a webservices component (Although thats where Andrew is heading) but all that is still up in the air so will probably change (Especially if roberts ideas get implemented)

[Gayle]

I don't think the full power of plugins has sunk in yet.
Certainly not with me, it's an area I really don't know much about.
Much earlier, Gayle suggested a similar idea with reference to automatically appending classes to Mambo.
<tries desperately to remember />

Was that the idea about providing fourth party functions to CMTs? If so, I'd completely forgotten about that! Still think it was rather cool though :)

[mmx]

The plugin concept forces you to think differently in many cases. For example, why should an e-commerce system require payment processor or shipping specific code dedicated its internal operation when one can write a payment or shipping manager component with plugins that could be shared among multiple e-commerce applications and other components. There are probably similar techniques that could be used when porting over a CRM, ERP, or project collaboration software. However, I admit that theorizing about doing this is much simpler than implementing those ideas.

The second paragraph goes all the way back to the old FUDforum. I think I still have a copy of the post buried in the bowels of my laptop at work. The parent Zencart project uses similar techniques to add queries to their query farm, classes and functions to their core, language definitions, javascript and extensions to their templating engine. Since no direct code hacking takes place, its very easy to customize and upgrade the core for various horizontal or vertical applications (e.g., customizing a store to sell computers or services rather than consumer product lines).

Certainly not with me, it's an area I really don't know much about.

<tries desperately to remember />

Was that the idea about providing fourth party functions to CMTs? If so, I'd completely forgotten about that! Still think it was rather cool though :)

[Gayle]

Ok, I did some experimentation with html2ps/Ghostscript and it took about 7 seconds to generate the PDF and used around 10MB RAM. I don't think that's realistic for a webserver and while I have some beautiful PDFs to show for it I had to do a lot of tweaking to get them. Parts of the core need to be changed (either that or on the fly modification of the HTML) to remove some page breaks that html2ps assumes when index2 is called as a popup.

Really, this is not a valid solution but it made for an interesting hour or so ;)

[mmx]

Ok, I did some experimentation with html2ps/Ghostscript and it took about 7 seconds to generate the PDF and used around 10MB RAM. I don't think that's realistic for a webserver and while I have some beautiful PDFs to show for it I had to do a lot of tweaking to get them. Parts of the core need to be changed (either that or on the fly modification of the HTML) to remove some page breaks that html2ps assumes when index2 is called as a popup.

Really, this is not a valid solution but it made for an interesting hour or so ;)

At some point in the process, a lot of RAM is going to be consumed because a PDF file is basically a binary version of a ASCII Postscript file, less the ps code used to handle formatting changes to the content. PS files can get very large depending on their complexity and they also can occupy large amounts of disk space. Adobe refers to the process as 'distillation' because only the parts of the ps file necessary to render a document remain in a pdf file after the process is completed. Code for handling interline spacing, leading, character spacing, etc. is removed. The reader fills in for the removal of that code and uses internal functions to display the portable document.

The overall process probably needs to begin with content stored in a generic format identical for all editors. Some sort of filtering method needs to be introduced to clean the content for individual editors before it is stored. Possibly, passing the content through something like Tidy as a preprocessing step might solve the problem. Some further cleanup might be necessary before rendering the pdf in the popup. Any other intermediate steps would handle the creation process. So, maybe we need a component-based event handler for chaining a selection of plugins in a sequence. In any case, some sort of definable process probably needs to exist with a chain of methods performed in a sequence. It might be possible to do something like this by chaining a series of filter-like plugins together to create a filtering process.

start -> plugina + pluginb + pluginc + plugind -> render

The sequence of filters used might vary for each process because of the various applications used to perform the overall process. Transforming to other formats like doc, mif, TeX, etc. might also be possible by mixing and matching a specific set of filters together in a process-dependent sequence. The parent process needs control the sequence, needs start and end feedback from the individual filters, and could handle error protection.

[tonyskyday]

Is it possible to cache the output of the pdf generator? It would be better to give up server space to a cached pdf doc than to give up RAM to creating a pdf every time anyone clicks the pdf button...

[unity]

I may be alone in this, but from where I'm sitting the decision to remove PDF support seems eminently reasonable and understandable, sad though others may find it.

We can discuss the technical aspects of this over and over but, being realistic, the main driver behind this decision is Adobe and the direction they're taking the PDF format.

The PDF format is becoming increasingly complex - too complex to allow the generation of PDF files 'on the fly' in an efficient and reliable fashion. the reason for this is simply that PDF for the web is only one small part of Adobe's overall plan for the format and one that is diminishing in important with each new iteration of the format.

Adobe's intentions are clear and well documented - it sees the PDF format's future much more in terms of its role as a reliable file exchange medium for the print industry and, as such, much of the development of the format is geared towards features and functionality that this industry needs - reliable and accurate rendering of high quality, high resolution and often complex layouts to pre-press standard.

As a result, I don't see this decision as the core team taking functionlity away from Mambo, merely an open and honest admission that its simply no longer practical to try to keep up with the direction that Adobe are moving the format, which increasingly, is futther and further away from the web.

[mmx]

The print aspect of PDF has existed since the beginning and started to get much better with Acrobat 4.0 and later. However, the use of PDF as a portable document format for the web is still under continuing development. At work, we frequently use Adobe's IAC interface into our own custom browsers and applications. Improvements to the library are still being continuously introduced. The Adobe ISO Javascript interface (based on ECMA Javascript 1.5) is publically available for download and its use is encouraged as a means of integrating Acrobat Reader, Acrobat, and Distiller support into web sites in conjunction with other languages.

Aside from the above, PDF format is an ideal proofing medium for the printing industry. After prepress preparation, any printer can provide a customer with a web link to a pdf document that they can examine and approve before a press run begins. So in this respect, continuing support for the web is still in the cards.

In Mambo's particular case, it makes sense to remove PDF generation support from the core (less worries and headaches for the core team). However, with some consideration for third-party elements, it should be possible to integrate this feature into Mambo for those who need it.

I may be alone in this, but from where I'm sitting the decision to remove PDF support seems eminently reasonable and understandable, sad though others may find it.

We can discuss the technical aspects of this over and over but, being realistic, the main driver behind this decision is Adobe and the direction they're taking the PDF format.

The PDF format is becoming increasingly complex - too complex to allow the generation of PDF files 'on the fly' in an efficient and reliable fashion. the reason for this is simply that PDF for the web is only one small part of Adobe's overall plan for the format and one that is diminishing in important with each new iteration of the format.

Adobe's intentions are clear and well documented - it sees the PDF format's future much more in terms of its role as a reliable file exchange medium for the print industry and, as such, much of the development of the format is geared towards features and functionality that this industry needs - reliable and accurate rendering of high quality, high resolution and often complex layouts to pre-press standard.

As a result, I don't see this decision as the core team taking functionlity away from Mambo, merely an open and honest admission that its simply no longer practical to try to keep up with the direction that Adobe are moving the format, which increasingly, is futther and further away from the web.

[spignataro]

I have to agree with Unity and part myself from the PDF functions.....

good bye PDF....

[tonyskyday]

I have no problem with PDF not being a core feature. I think Phil's reasoning is perfectly valid. But, hasn't this discussion moved on to brainstorming a third-party method? And also, discussing how it would hook into Mambo?

[grutkowski]

I may have missed this earlier in the thread, but has anyone considered using FDF/XFDF and a template PDF form for basic core PDF 'generation'?

This solution requires very little server side resource (no more than creating typical XML) and has no inherent dependancies. The PDF is displayed on the client side by combining the XFDF data with the PDF Form. Really quite similar to RSS...

This isn't to say I wouldn't like to see the whole process externalized - I'd love to see some good hooks for 3rd party solutions, but I do think that some form of PDF support should be included - if only to be able to say it's there.

[al_stone]

Was the removal of PDF functionality on the official Mambo roadmap or was this an <<off-map>> decision?

Just curious

Alan

[spignataro]

i beleive this was an off road map....this was a decisions that was made due to the facts dicussed in this post.

[fogfire]

Yes... I prefer to have simple PDF vs. No PDF

I am wokring on a business plan that was going to use the PDF feature. So I would be left out of Mambo Moving ON.

There is a large company in Redmond that contrary to lots of claims, made much of its success by respecting the customers needs and suffering the pain of draggin legacy features along until 90% or more had no need.

I was sort of sorry to see the response to "can we keep if for legacy support" was "shut up"

I am not a developer, just a person building Mambo sites for my clients. And for text oriented sites, PDF worked just fine. I was sorry to see that since I don't send in code, my opinion is seen by some on the Mambo team as worthless.

The key to success is customer focus... of course one trap of free software is there is no metric to motivate measure customer satisfaction.

This user... votes for moving forward without abandoning existing users. I have not seen a case that say PDF will hold new Mambo sites back, if there is on please explain. New sites can ignore the feature while current sites can stay updated and still have it.

I for one really appreaciate all the work of the Mambo team, and I also appreciate people willing to question decisions...when careful or not, they are made without user feedback.

Some of the comments on this thread say Mambo needs a Product Manager.. someone whose job is to think about the users, not just standards and technology.

Ken

[spacemonkey]

Woah there, fogfire. I'll take these on one at a time.

Yes... I prefer to have simple PDF vs. No PDF

I am wokring on a business plan that was going to use the PDF feature. So I would be left out of Mambo Moving ON. It is not gone forever, it is just getting removed from the core. Read on for a rational explanation ;)

There is a large company in Redmond that contrary to lots of claims, made much of its success by respecting the customers needs and suffering the pain of draggin legacy features along until 90% or more had no need. That large company in Redmond had to, because they wouldn't let anyone else develop third party goodies. That is what this talk is all about, whether it should be in the core or separate.

I was sort of sorry to see the response to "can we keep if for legacy support" was "shut up" Hey, you didn't hear that from me. And I can tell you it is equally distressing to put together polls where you want to hear what the community wants, and then you are told your poll is stupid and has all the wrong options... But no, I'm not bitter! ;)

I am not a developer, just a person building Mambo sites for my clients. And for text oriented sites, PDF worked just fine. I was sorry to see that since I don't send in code, my opinion is seen by some on the Mambo team as worthless. But then that is your opinion on their opinion about your opinion. I'm confused.

The key to success is customer focus... of course one trap of free software is there is no metric to motivate measure customer satisfaction.

This user... votes for moving forward without abandoning existing users. I have not seen a case that say PDF will hold new Mambo sites back, if there is on please explain. New sites can ignore the feature while current sites can stay updated and still have it.

I for one really appreaciate all the work of the Mambo team, and I also appreciate people willing to question decisions...when careful or not, they are made without user feedback. I have a customer right now that had a custom template made, and it was done in pure XHTML/CSS for accessibility and adherence to standards. That template rendered the PDF output completely broken. Do they understand it is because the PDF library available doesn't understand CSS yet?

Nope, they think Mambo is horribly broken.

Splitting the PDF output to a separate package ensures that what you get in the core works. If you wish to impose the limitations of the PDF output library on your template, then by all means go for it. But there are other people that are not interested at all in PDF output, and have tempates built to adhere to certain standards (government requirements, for example); and when they see PDF functionality advertised they expect it to work...

Some of the comments on this thread say Mambo needs a Product Manager.. someone whose job is to think about the users, not just standards and technology. Some of us make a living doing nothing but Mambo, me included. My clients are tiny little family businesses, huge international corporations, and non-profit organizations that fight for human rights. This is a really wide range of needs and focus, and they all are in fact Mambo users too ;)

I don't see what all the fuss is about if the existing PDF code is available as an external addition. That way you can keep your PDF-purposed content, and people that are new to Mambo won't think we implement broken code.

[absalom]

I have a customer right now that had a custom template made, and it was done in pure XHTML/CSS for accessibility and adherence to standards. That template rendered the PDF output completely broken. Do they understand it is because the PDF library available doesn't understand CSS yet?

Nope, they think Mambo is horribly broken.


Actually, that sounds like you didn't do a print stylesheet (or your existing layout wasn't compatible with standard print rendering). I've been subject to this kind of support request that you state above, and it's not the PDF engine's fault, but the CSS..

[spacemonkey]

Actually, that sounds like you didn't do a print stylesheet (or your existing layout wasn't compatible with standard print rendering). I've been subject to this kind of support request that you state above, and it's not the PDF engine's fault, but the CSS.. Nope - the client expects images in content to appear in the PDF output as well; and the only way at this time is to have HTMLDoc installed on the server, which does not support CSS.

I have yet to have someone that was happy with their site spitting out PDFs that were missing the graphics, as sometimes that is just as important as the text.

If you know how to create an XHTML template that validates, with both screen and print media formatted CSS, and output PDFs that include the images and leave UL/OL formatting intact, then we need to talk! :D

[stingrey]

Actually, that sounds like you didn't do a print stylesheet (or your existing layout wasn't compatible with standard print rendering). I've been subject to this kind of support request that you state above, and it's not the PDF engine's fault, but the CSS..As Mitch says, if someone believes they have aworkable solution, we would be happy to examine it.

However as far as I am aware there is no free (as in GPL) pdf library that can convert a fully xhtml/css compliant page to pdf that does not require the installation of an anothor program onto the webserver like htmldoc.

So the key is the pdf creation library needs to:
- be free for use
- be able to handle converting a fully xhtml/css page
- can handle inclusion of images
- does not require installation of any other other programs to work


If anyone thinks they know of something that meets all these criteria, then we would only be happy to examine if it could be used with Mambo.
The Team ave looked and havent found anything that can meet these requirements, but new things are always popping up, so how nows, maybe something does exist out there in the wild

[PhilTaylor (aka PrazGod)]

As Mitch says, if someone believes they have aworkable solution, we would be happy to examine it.

However as far as I am aware there is no free (as in GPL) pdf library that can convert a fully xhtml/css compliant page to pdf that does not require the installation of an anothor program onto the webserver like htmldoc.

So the key is the pdf creation library needs to:
- be free for use
- be able to handle converting a fully xhtml/css page
- can handle inclusion of images
- does not require installation of any other other programs to work


If anyone thinks they know of something that meets all these criteria, then we would only be happy to examine if it could be used with Mambo.
The Team ave looked and havent found anything that can meet these requirements, but new things are always popping up, so how nows, maybe something does exist out there in the wild
I think i have made this point loads of times :-) :-)

[Virtuozzo]

Well, this topic finally made me register - long overdue, I know .. but this really raised a few eyebrows here :)

I understand the motivations for not continuing the pdf functionality as a core element, however I cannot see Mambo without this functionality as a core feature.
This for the simple reason that most sites served with it in our own domains as well as those of partner institutions either directly rely on the pdf functionality or (!) have selected Mambo directly because of that functionality.
Motivations for that vary depending on the market sector and plenty of arguments for them but the one thing that is shared is that pdf conversion is the one feature most valued because of its direct usage in day to day life and work -> most institutional sites are more like intranets then the common presentation website. Pdf documentation is a requirement for most post publishing processes. Not to mention the legal requirements for most articles published with pdf being the only government recognised document standard (for reasons beyond me but ..).

On the side but still important -> I can't help agreeing with a post a bit back referring to the good old print stylesheets :)
Regardless of the pdf engine debate I would not understand why any site / template would not by default provide different media types, after all viewing a site is not restricted to the referrer of windows xp + msie 6 :) Granted, it does cause a bit more of a development curve for templates but using multiple types of stylesheets might not be a bad idea, perhaps a requirement (so to speak) for templates of having a print type stylesheet by default could make it easier to keep the pdf functionality (if printing to pdf, only the article via the print stylesheet) - or am I missing something.

The bit of the pdf engine ... not my point of view but something expressed to us by other organisations using Mambo -> not a core functionality could / would open a path towards a third party (commercial) alternative. Some of those people have actually moved away from other systems who in the past moved to either a proprietary commercial addin engine or opened the road for a third party addin, both cases however resulting after a year or so in a scenario of per seat licensing ...
I can't really see that happening with the Mambo scene, but I can understand their worries. Personally I would not mind if pdf functionality went commercial, though not in an "enterprise" style :) Perhaps it is time or opportunity to take a few features not commonly crucial except for the more affluent client groups and not provide them in the standard Mambo build but provide them via a sponsor purchase (single) system (yeah .. I've run into that nuke some time ago) - just a bad idea :)

Anyway ....

[PhilTaylor (aka PrazGod)]

Well, this topic finally made me register - long overdue, I know .. but this really raised a few eyebrows here :)

I understand the motivations for not continuing the pdf functionality as a core element, however I cannot see Mambo without this functionality as a core feature.
This for the simple reason that most sites served with it in our own domains as well as those of partner institutions either directly rely on the pdf functionality or (!) have selected Mambo directly because of that functionality.
Motivations for that vary depending on the market sector and plenty of arguments for them but the one thing that is shared is that pdf conversion is the one feature most valued because of its direct usage in day to day life and work -> most institutional sites are more like intranets then the common presentation website. Pdf documentation is a requirement for most post publishing processes. Not to mention the legal requirements for most articles published with pdf being the only government recognised document standard (for reasons beyond me but ..).

On the side but still important -> I can't help agreeing with a post a bit back referring to the good old print stylesheets :)
Regardless of the pdf engine debate I would not understand why any site / template would not by default provide different media types, after all viewing a site is not restricted to the referrer of windows xp + msie 6 :) Granted, it does cause a bit more of a development curve for templates but using multiple types of stylesheets might not be a bad idea, perhaps a requirement (so to speak) for templates of having a print type stylesheet by default could make it easier to keep the pdf functionality (if printing to pdf, only the article via the print stylesheet) - or am I missing something.

The bit of the pdf engine ... not my point of view but something expressed to us by other organisations using Mambo -> not a core functionality could / would open a path towards a third party (commercial) alternative. Some of those people have actually moved away from other systems who in the past moved to either a proprietary commercial addin engine or opened the road for a third party addin, both cases however resulting after a year or so in a scenario of per seat licensing ...
I can't really see that happening with the Mambo scene, but I can understand their worries. Personally I would not mind if pdf functionality went commercial, though not in an "enterprise" style :) Perhaps it is time or opportunity to take a few features not commonly crucial except for the more affluent client groups and not provide them in the standard Mambo build but provide them via a sponsor purchase (single) system (yeah .. I've run into that nuke some time ago) - just a bad idea :)

Anyway ....
It is obvious you do not understand the technical aspect to the generation of PDF's from source HTML. If you did you would understand that you cannot just format using CSS and then convert to PDF and get a great looking, image rich PDF - It just doesnt happen

I personally researched for many weeks a solution - which was simple yet could work on all systems (As mambo prides its self on running on almost zero dependancies) - none were found.

As the official statement said - the decision was not taken lightly.

Phil.

[Virtuozzo]

It is obvious you do not understand the technical aspect to the generation of PDF's from source HTML. If you did you would understand that you cannot just format using CSS and then convert to PDF and get a great looking, image rich PDF - It just doesnt happen

I personally researched for many weeks a solution - which was simple yet could work on all systems (As mambo prides its self on running on almost zero dependancies) - none were found.

As the official statement said - the decision was not taken lightly.

Phil.Hm, I must have touched a nerve there - if I did, I apologise. But yes, I do not understand one bit of technicalities :) All I have seen sofar is the resources supplied to the projects related and the results, alternate stylesheets are in heavy use around here for obvious reasons. As for getting from a standard Mambo published article to a pdf created by means of an alternate stylesheet ... I'd have to ask the folks who do the technicalities as it does seem to work (there's a medical institute nearby for instance who use Mambo on a staff intranet where the pdf's are most valued for submissions for validation prior to publishing by the administrative and legal staff). But as I said: perhaps I have missed something and that functionality is not the standard functionality. Or perhaps it is related to the zero dependencies target mentioned, could very well be.

I can imagine the decision to be not taken lightly, it is functionality after all valued by many not using Mambo for presentation sites. I hope the bits on relative concern for commercial pathways expressed in the original post did not get lost in the secondary responses btw :)
Again: I can understand the motivations and arguments, but I do hope a balance is found as the pdf functionality is highly valued around here - regardless of core or commercial (as long as it is sensible) :)

[spacemonkey]

I understand the motivations for not continuing the pdf functionality as a core element, however I cannot see Mambo without this functionality as a core feature. Do you know of any FOSS PDF libraries with a small footprint that support CSS-P? This is the biggest killer for us - as new site templates are designed with CSS usage, the PDF export capability is left behind. It just doesn't work. So the only time it does is when you do the whole template in tables, which is bad for a gazillion different reasons (and in many cases, not possible due to accessibility and so on)...

On the side but still important -> I can't help agreeing with a post a bit back referring to the good old print stylesheets :)
Regardless of the pdf engine debate I would not understand why any site / template would not by default provide different media types, after all viewing a site is not restricted to the referrer of windows xp + msie 6 :) Granted, it does cause a bit more of a development curve for templates but using multiple types of stylesheets might not be a bad idea, perhaps a requirement (so to speak) for templates of having a print type stylesheet by default could make it easier to keep the pdf functionality (if printing to pdf, only the article via the print stylesheet) - or am I missing something.
I did this quickly for my old site just as an example - www.spacemonkeylabs.com (http://www.spacemonkeylabs.com) - I took Andy's SolarFlare (default in 4.5.1a), changed the header graphic, and added a minimal print stylesheet. Load the site and hit 'Print Preview' in your browser, and you will see what I mean. Please feel free to use that layout as an example.

This capability is actually old, but IE only supported it with 6+. Hopefully everyone will start to see how powerful CSS is; and hopefully the browser wars being restarted will force Microsoft to bring their antiquated IE up to a manageable level of functionality and standards support.

I can't really see that happening with the Mambo scene, but I can understand their worries. Personally I would not mind if pdf functionality went commercial, though not in an "enterprise" style :) Perhaps it is time or opportunity to take a few features not commonly crucial except for the more affluent client groups and not provide them in the standard Mambo build but provide them via a sponsor purchase (single) system (yeah .. I've run into that nuke some time ago) - just a bad idea :) Yuck. I intentionally avoided other CMS in the past because I got the feeling I would have to load up on a bunch of commercial add-ons just to have a usable system. I sure hope that is not the direction we end up going.

I am working on several custom sites that need PDF output with great control, and the only way I know how to really do it right is to use FPDF. FPDF is a great library (and doesn't require you to install any other software, just works in PHP). BUT...

FPDF does not really take HTML and just spit out a PDF - you have to rip the content out of the content, and use FPDF's method calls to setup the format of the document. So we cannot use it, as we are spitting out HTML before the conversion process. This problem, combined with the fact that there are no PDF libraries that understand CSS, combined with the fact that people are starting to use CSS-only for their layouts and templates, leaves us at a significant disadvantage.

To a significant number of our users, the existing PDF output is flat broken and completely unusable. And this is our dilemma... And in that scenario, you have to ask if it makes sense to keep something in the core that only works for certain people under certain conditions. Does that really make sense?

[tonyskyday]

I still vote for including "hooks" in the core for people do use commercial or other PDF generation methods that work better. That way, htmldoc or whatever can be a dependency of that third-party plugin, rather than of the Mambo core.

[spignataro]

Here is a solution. How bout there be 3 differant component functions for the PDF (i beleive there are 3 differnat pdf converting classes if im not mistaken) and these can be available for those who wish to have PDF intergration at there own risk.

[stingrey]

Due to the current change in our roadmap and development structure, PDF support will continue to be supported in the 4.5.x Maintenance series.


However, at this stage - unless a viable alternative exists - it will be depreciated in 5.0

[efrog]

Yay! Because that's one of the things I LOVE about Mambo that made me all *Woooo!* that's AWESOME!

:)
~K

[Bigb]

I just read all the thread and I make some research

Here you can find some useful projects to start:

http://html2fpdf.sourceforge.net/

http://xhtml2pdf.mandragor.org/

both projects are based on fpdf so they don't need any additional librairies, but they seem to be stopped

PDF rendering is definitvely a great feature for Mambo


PS: I could help on this project (not for the moment but I will be available for a long time)

[swordhert]

thats good decision to remove pdf support :grin:

i dont need pdf :grin:


IMHO we should concentrate our development teem to work on image upload from frontend (and make this thing secure)

[mmx]

Whether it stays in or gets removed is probably not a problem. Third-parties will introduce support for PDF for those who need it.

[Hackwar]

Hi folks,
as thede has kindly told me in another thread, Mambo 5.x will use patTemplate. On the same page you can get patXMLRenderer, that creates PDFs out of XML-files. Would it be so difficult to incorporate this? I mean, the code created by the editors "just" has to be converted to an XML. Would a converter be that difficult to code?
Just a sugestion.
Hackwar

[spignataro]

that is actually not a bad idea