PDF Functionality In 1.6

42 views
Skip to first unread message

Ercan Özkaya

unread,
Apr 13, 2009, 5:22:26 PM4/13/09
to Joomla! CMS Development
Hello,

As you can see on the roadmap for 1.6, PDF functionality is to be
examined and dropped if necessary. We wanted to ask about what people
think for leaving this feature to third party community.

First my reasons for wishing to drop that from core:
1- It's not a very needed feature anymore to have a pdf for each
content item on your site.
2- It was a maintenance nightmare in 1.5 (Try searching for pdf in 1.5
tracker: http://tinyurl.com/35xr9x)
3- The library itself is updated very often and we can't just update
it for each maintenance release we do.
4- It does not work very good anyway at the moment. You can't use
plugins on it for example.

We could keep support for PDF document type in JDocument if necessary
and it would be very easy to create a third party component for this.
And we also get rid of about 1 mb in package size after dropping this.
A nice gain.

So what do you think?

Lukas Polak

unread,
Apr 14, 2009, 4:55:39 AM4/14/09
to joomla-...@googlegroups.com
Hi,

I definitely agree with this. After what I've seen, PDF functionality
should be yield to third party community, which have more time to
mainterance the current working version of it and you, guys, can focus
on more serious issues and features for joomla. that's mine opinion.

elf

Ercan Özkaya wrote / napísal(a):

Bojan

unread,
Apr 14, 2009, 5:49:35 AM4/14/09
to joomla-...@googlegroups.com
I agree as well with dropping the PDF Functionality in the joomla 1.6 it
is clunky and not as usefull, but please note that a lot of people are
used to having PDF on their sites, it would most certainly cause a big
array of panic and confusion among the administrators that are not so
well familiar with the production of joomla, and do not read the changelogs.

Bojan.

Lukas Polak

unread,
Apr 14, 2009, 6:38:38 AM4/14/09
to joomla-...@googlegroups.com
This isn't exactly true, because they have an option to install third
party library for it, what, after all, they did many times because
actuall pdf library has to be updated almost every month to keep it as
much functional as it is possible, so therefore I don't problem with it.

elf

Bojan wrote / napísal(a):

infograf768

unread,
Apr 14, 2009, 12:15:33 PM4/14/09
to Joomla! CMS Development
Not sure I agree with this.
A few remarks:

1. Last version of tcpdf has really much evolved since the older
version we have in 1.5 (last version is 4.5) and it is only (library +
freesans fonts) a bit more than 500k tgz
2. Yes, the library is updated frequently, but of concern to us are
only major versions (i.e. 2, 3, 4 ). Also, the developper (Nicolas
Asuni) is very responsive and any suggestions we would do would be
listened to and implemented.
Btw, we have the same issue with TinyMCE. We are just starting
discussing updating to Tiny 3.
3. The most important "bug" is IE7 pdf display (there is a solution in
doc.joomla by Mark) which is NOT tcpdf related, but a Micro$oft issue.
4. A more current issue happens when there is local formatting in
content, defining font-family, a bad habit anyway.
In this case tcpdf chokes because it does not find the font. A good
help and some overlibs should document this better.
5. No one has really tested (unit-test) last versions. My non-unit-
tests show here a real improvement on most aspects (Tables, RTL,
specific multibytes languages).
6. Joomla users expect this feature.
7. The only 3rd party solution I know of and which is not commercial
(Phoca PDF) installs OK here but I can't get it to work on a 1.5.10
or earlier. It has still been in alpha stage for months.
8. Plugins do not work in 1.5 pdf because it is not implemented in
view.pdf.php

JM

Leftfield

unread,
Apr 14, 2009, 12:58:59 PM4/14/09
to Joomla! CMS Development
For me, it was sad enough with: "6. Joomla users expect this feature."
PDF function is/was so much standard feature that i can't image Joomla
without it.

Niels Braczek

unread,
Apr 14, 2009, 2:07:44 PM4/14/09
to joomla-...@googlegroups.com
Leftfield schrieb:

> For me, it was sad enough with: "6. Joomla users expect this feature."
> PDF function is/was so much standard feature that i can't image Joomla
> without it.

Same with me.

Regards,
Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

Lukas Polak

unread,
Apr 14, 2009, 2:47:08 PM4/14/09
to joomla-...@googlegroups.com
Honestly, how many of you came across any web page with pdf export? I've
seen it only once - on a page I helped with ... therefore I don't see a
point in keeping this libraby in Joomla core ... let developers focus on
other, more important features and issues

elf

Niels Braczek wrote / napísal(a):

Amy Stephen

unread,
Apr 14, 2009, 4:58:02 PM4/14/09
to joomla-...@googlegroups.com
I tend to agree with JM that I see this as a better core function, than a third party extension. For one, I think it would be difficult to position all of the buttons together that offer print preview, email, and PDF output. I also think it's a nice feature - but, not a showstopper, if absent.

However, I think the bigger question is this -> do we have a volunteer who wants to put the time into coding this?

Wanting and doing are two different things. If someone does it - let's include it.

My 2 cents,
Amy

Ian MacLennan

unread,
Apr 14, 2009, 5:00:42 PM4/14/09
to joomla-...@googlegroups.com
I personally think the better route to go is to make it easier to add buttons using plugins, but that seems out of scope for 1.6.  Then you could take out all three and make it completely third party.

Ian

Niels Braczek

unread,
Apr 15, 2009, 1:46:12 AM4/15/09
to joomla-...@googlegroups.com
Lukas Polak schrieb:

> Honestly, how many of you came across any web page with pdf export? I've
> seen it only once - on a page I helped with ... therefore I don't see a
> point in keeping this libraby in Joomla core ... let developers focus on
> other, more important features and issues

People do not like, if you take anything away from them. Dropping native
PDF support would lead to negative publicity. The only alternative, I
see, is to have a PDF addon *ready and working*, that integrates into
the core as seemlessly as the current solution, and *then* remove it
from the standard installation.

Schalk Versteeg

unread,
Apr 15, 2009, 2:33:30 AM4/15/09
to joomla-...@googlegroups.com
Please keep it, as it is one of the reasons I went for Joomla for our companies Intranet.
It is especially useful for documentation and policies and not needing to update two different versions of the same document is a real advantage.

Schalk Versteeg

Robert

unread,
Apr 15, 2009, 3:00:55 AM4/15/09
to Joomla! CMS Development
I agree with JM. I think we get in problems when we remove it. Some
people like it and atm it works (not very good but it works). So we
need a very good reason to remove it.

Robert


On 15 Apr., 08:33, Schalk Versteeg <schalk.verst...@gmail.com> wrote:
> Please keep it, as it is one of the reasons I went for Joomla for our
> companies Intranet.It is especially useful for documentation and policies
> and not needing to update two different versions of the same document is a
> real advantage.
>
> Schalk Versteeg
>

Hannes Papenberg

unread,
Apr 15, 2009, 4:35:11 AM4/15/09
to joomla-...@googlegroups.com
Hello Robert,
you are giving the reason to remove it yourself: It just kinda works.
There is no real way to style the PDF, adding a corporate header is
everything else but easy in Joomla. Plugins don't work and even if we
would enable plugins for PDF, this would make matters worse than better.
(Why would you want to have the comments to an article in the PDF along
with the commenting form?) Also, I myself would prefer to be able to
link to a PDF document instead of generating it on the fly all the time.
There is a lot of potential for third party developers here, which we
are suppressing with the support in Joomla core.

I've been hesitant to vote for removing it, since I don't like removing
functionality either, but while looking into this, I've seen the
problems and the potential in there. Of course it should be possible for
third party developers to bring this feature back. If they want to, it
has to be possible to do this in the exact same way it is done now. This
would force us to do some small changes that I would see as an
improvement, for example providing a way to add your own icons to the
list of print, email, pdf, etc. Then again, when we are talking about
PDF generation, it is currently done on the fly, which could produce
quite some load on the server. A third party developer could do all this
with one simple plugin that caches this article as a PDF to the
filesystem upon saving an article. Such a plugin could also add funny
stuff like forced page breaks that differ from the pagebreaks on the
HTML page. Above all, that plugin could put the whole PDF into your
corporate design.

Yes, a lot of maybes, but such extensions wont become reality if we
still support it in the core.

Keeping it just because its currently in the core, is no argument.
Following that resoning, we'd had to keep com_section and com_poll, too.
Both of which I'm very happy that they are gone.

Hannes

Robert schrieb:

Robert

unread,
Apr 15, 2009, 7:02:50 AM4/15/09
to Joomla! CMS Development
Hi Hannes,

it is easy to say there is many potential for third party developers.
There is also many potentail for com_content or com_weblinks, should
we also remove this? I think if I don't have a better solution why
should I remove a function. Again, it works, it could be better ...
but let us talk about better functionality and not about a remove and
wait for anyone who can make the job better as we have done it in the
past.

Robert

Alex Kempkens

unread,
Apr 15, 2009, 9:34:18 AM4/15/09
to joomla-...@googlegroups.com
Hi folks,

I know Louis is thinking about a new way of dealing with articles in general. I'm sure if we think about the way we deal with articles from scratch there are options that allow us easily to include things such a simple plugable PDF support as well.

I personally would also not drop the support mostly because I know various clients that use this feature in their intranets and project documentations.

Moving the icons (such as mail, pdf or print) into a plugin schema shouldn't be that difficult and this way we can make it possible to replace the core functionallity if better PDF support is needed. But dropping it in core I don't feel good with.

Alex

Amy Stephen

unread,
Apr 15, 2009, 9:38:42 AM4/15/09
to joomla-...@googlegroups.com
Is there a developer willing to help with this work?

Alex Kempkens

unread,
Apr 15, 2009, 9:43:46 AM4/15/09
to joomla-...@googlegroups.com

Am 15.04.2009 um 15:38 schrieb Amy Stephen:

> Is there a developer willing to help with this work?

I think we first need to agree on what "this work" is, Amy.

I would be willing to help on the new definition of the article
management as this is something I think we should really start doing.
However I'm considering this as not priority for 1.6 and would just
start with the work. If we have something achieved until a first dead-
line for 1.6 we can slip it in - if not it goes into 1.7.

Alex

Amy Stephen

unread,
Apr 15, 2009, 10:10:00 AM4/15/09
to joomla-...@googlegroups.com
I agree 100%, Alex, planning is essential, and identifying resources is a key part of that process. Please do not take offense by my comments -- I frequently recruit developers for many identified tasks for 1.6. Since this is not an alpha-blocker, or, as you have explained, a priority, turning to the community is important.

For those who really want to see this available, try to find someone who can help make this happen. If someone is willing to code, please post.  Having a volunteer doesn't mean this is the direction we will head - but it would be remove one more barrier from consideration.

Thanks!
Amy :)

JM Simonet

unread,
Apr 15, 2009, 11:39:34 AM4/15/09
to joomla-...@googlegroups.com
Amy,
In fact, as Hannes updated the library, tcpdf works better in 1.6 than it does in 1.5.

Remains to be decided what can be done on Joomla side to improve the output.

Looks like
1. We could already patch to get it to work in IE7.
2. Being able to load some content plugins by entering parameters in the Article parameters would be a plus.
For example Loadmodule. I do agree with Hannes that loading ALL plugins makes no sense. Getting rid of unwanted plugins calls would also be a plus.
3. An other matter is transforming the relative urls to absolute when creating the pdf.
4. Concerning the headers, this could also be a parameter in Articles parameters.

Hannes,
Personnaly I would rather get rid of weblinks than pdf in Joomla.
After all, weblinks are just specific categories.
PDF functionality is unique.
No comparison with com_sections either.
Also I remarked this comment:
"but such extensions wont become reality if we still support it in the core."
I disagree with this. It does not prevent 3rd party to make specific extensions which aim would be, as you say, saving a pdf in the file system when saving an article (which I would never do btw as my host would not like it, even more a Chinese host ;) )
If we were following that line, it could mean indeed that mail functionnality, Newsfeeds, Wrapper could easily go and wait for 3rd party extensions to be released.
It would be IMO a bad policy for Joomla!
Users are expecting long waited-for functions, not dropping down what they count on and can't easily be replaced.
The new ACL is the main new aspect of Joomla! we all have been expecting since the Mambo times.
Let's enjoy that one and make better what can be of what we have.

JM

Hannes Papenberg

unread,
Apr 15, 2009, 11:44:06 AM4/15/09
to joomla-...@googlegroups.com
I don't want to discourage anyone, but rewriting com_content for 1.6 is
completely out of the question. We have a pretty specific feature list
for 1.6 and that list already is pretty long. We are also practically a
year late on 1.6 development. I wont tolerate any more unnecessary
delays. Among other things, a rewrite and a new structure for
com_content is one of the big candidates for 1.7, but for 1.6 it is out
of the question.

We could argue about creating a first PDF plugin, which is then released
on the JED, if we decide to remove the library from core.

Hannes

Amy Stephen schrieb:

Alex Kempkens

unread,
Apr 15, 2009, 12:32:22 PM4/15/09
to joomla-...@googlegroups.com
Amy, sorry but did you read what I wrote?


May be I repeat it to make it clear.
If we are talking about implementing the new article manager that can include a new plugin system for PDF functionality I'm willing to contribute/code to this.

The whole PDF topic is not a priority for 1.6 as far as I know. If we are now looking only on alpha-blocker I suggest we post-pone this discussion and focus on those things that are defined as alpha-blocker for 1.6 only. 

Alex

Alex Kempkens

unread,
Apr 15, 2009, 12:36:20 PM4/15/09
to joomla-...@googlegroups.com
Hi Hannes,

Just to make myself clear as I have the impression people understood my post wrong.

Yes this rewriting is out of scope.
From my personal view it is independed from the other topics that are addressed for 1.6. 
This is the reason why I think it is possible to start working on it and contribute it at the time it is ready. This way we will have better planing and options for 1.7, right?

Alex

Hannes Papenberg

unread,
Apr 15, 2009, 12:37:08 PM4/15/09
to joomla-...@googlegroups.com
This is not defined as an alpha blocker, but it would be nice to decide
this before alpha, so that people will ideally be able to just copy
betas over the alpha to upgrade, instead of having to completely
reinstall or delete files manually. Thats why we've already cleaned up a
lot of the trunk now.

Hannes

Alex Kempkens schrieb:

Erdősi Gergő

unread,
Apr 15, 2009, 1:59:05 PM4/15/09
to joomla-...@googlegroups.com
As it was said before, this is not a 'Who likes it?' question. There
are a lot of tasks and if we want to keep it in the core, we need at
least one volunteer, who can update the library, create a patch for
the mentioned tasks and do all of this until the beta release. And of
course he/she needs to maintain it in further (maintenance) releases.
We need help and volunteers, a simple 'I like it' doesn't help in a
decision.

--
Erdősi Gergő
http://www.joomline.hu - Joomla! fejlesztői oldal


2009/4/15 Hannes Papenberg <hack...@googlemail.com>:

Omar Ramos

unread,
Apr 15, 2009, 3:46:26 PM4/15/09
to joomla-...@googlegroups.com
Is there a list of the current shortcomings of PDF support in Joomla 1.5?

As far as I've been able to gather, PDF support (as in full-featured classes/libraries) in PHP in general seems to be fairly lacking in the open source area. Louis also mentioned during the JoomlaDay Las Vegas that TCPDF doesn't buffer its output currently so it makes it difficult to use it within JDocument as it is used for HTML pages.

Last week I came upon the Mars Project in Adobe Labs, which is an XML representation of the PDF file format, and it was created about 3 years ago so I'm thinking it will make its way into a release of Acrobat soon (though there are plugins available on the labs site that add support for the format right now). I wanted to look into building support for this format, since I believe it would be simpler than trying to tackle the actual PDF format, and plus it seemed a bit forward thinking in terms of what Adobe is probably planning themselves.

The same also goes for the .docx format and .xlsx (though this last one is currently being tackled by the PHPExcel team), and also ODF support for the completely Open Source folks.

I think including specific output formats is really handy to include within the framework itself, since it makes things simpler for developers, and also because there aren't very many libraries out there that allow one to output content into the formats above.

This would require some amount of dedicated resources, so it wouldn't be something that could be accomplished right away, but those output formats come in mighty handy for enterprisey-type applications where people want reports generated from the data input into the application.

-Omar

2009/4/15 Erdősi Gergő <gergo....@gmail.com>

Lukas Polak

unread,
Apr 15, 2009, 5:29:46 PM4/15/09
to joomla-...@googlegroups.com
I've thought it over and i think that moving these buttons to plugin
phase would help third party extensions and solved this problem since
this problem would be totally up to third party which is more flexible
... tcpdf can remain implemented as plugin and therefore it can be
replaced just like WYSIWYG editor is... this will definitely help
developers to gear up with developing such kind of extensions even for
another formats as it was mentioned below by Omar.

elf

Omar Ramos wrote / napísal(a):
> <mailto:gergo....@gmail.com>>
>
>
> As it was said before, this is not a 'Who likes it?' question. There
> are a lot of tasks and if we want to keep it in the core, we need at
> least one volunteer, who can update the library, create a patch for
> the mentioned tasks and do all of this until the beta release. And of
> course he/she needs to maintain it in further (maintenance) releases.
> We need help and volunteers, a simple 'I like it' doesn't help in a
> decision.
>
> --
> Erdősi Gergő
> http://www.joomline.hu - Joomla! fejlesztői oldal
>
>
> 2009/4/15 Hannes Papenberg <hack...@googlemail.com
> <mailto:hack...@googlemail.com>>:
> <mailto:alex.k...@gmail.com <mailto:alex.k...@gmail.com>>>

ot2sen

unread,
Apr 17, 2009, 3:57:26 AM4/17/09
to joomla-...@googlegroups.com
Hi Ercan,
 
Find it a highly interesting question that you raise here. "Is native PDF support needed in 1.6?"
Have been thinking about the pros and cons the last week, and is still sort of undecided.
 
Obviously there are some known issues with end-users not having the pdf generated when using their preferred browser, which results in webmasters turning the feature off. And there are other issues that most companies using the feature, request some modification in order to present header/footer.
And not to forget the extra work on joomla devteam on keeping this updated.
 
So its a valid question, if we should still support PDF in core.
 
An easy way to test the waters, whether this feature is actually widely used would be to set Show Pdf to No in next 1.5.x release, and see if anyone really notice...and if A LOT notice and react, then let the devteam respond in the forum :p
 
Understand the arguments from JM and others that its hard to remove a core feature like this. That said, I still find it should work as expected when its included (not like the current state with too many hickups..)
 
Should it be removed then the (7.) that JM mentions, is certainly a pretty neat 3rd party alternative.
Works fine at my tests at 1.5.10, and works fine in IE7..., and you can easily add your own headers/footers, choose font, colors, and its plugable for other 3rd party extensions.
To me this is a 3rd party alternative, that I would choose over the core default feature as it is today.
 
Just my 2cents
 
Ole


 
2009/4/15 Lukas Polak <polak....@gmail.com>

Jan (Phoca)

unread,
May 12, 2009, 4:32:29 PM5/12/09
to Joomla! CMS Development
Hi, there are my ideas about PDF suggested in other group (sorry for
my poor English):

For 3rd party component there are two main problems for creating some
PDF behaviour:
1) while installing component, the component (mostly) doesn't have
access to install some document type to: libraries/joomla/document/
folder. Installing document type there doesn't make disorder in
Joomla! system structure.
2) 3rd party component needs to create link to PDF document. So e.g.
in article content the link must be hardcoded or there must be used
some system listener which will search the content code and will paste
somehwere the link to PDF document (like any other listener this can
slow down the system), or there can be some plugin. Plugin code can be
displayed in the content but mostly the print or pdf icon should be
displayed before (above) content not in the content :-( so using
standard content plugin is not good solution :-(

My ideas about PDF in Joomla! 1.6:

1) I think, there should be new class JPDF in Joomla! libraries. This
class should extend the TCPDF class (in core TCPDF class there
shouldn't be any changes so it can be actualized easy). So JPDF class
will contain above all the Header() and Footer() method which will
override the basic TCPDF methods. This methods can get parameter
values, so user will be able to customize the PDF.

There are two possible ways of getting and saving parameter values:

a) Parameters will be a part of e.g. com_pdf component in Joomla! (in
case there will be com_pdf component which will care about PDF
creating of articles)
b) or Parameters will be a part of e.g. plg_content_pdf, some plugin
which will care about PDF creating of articles in Joomla! If there
will be a system of plugins, then other PDF plugins for other Joomla!
components can be installed.

The JPDF class should contain method which recognize the user's
browser. In case user will use IE7, there will be implemented hack for
opening the PDF document in popup window in IE7 (which now don't work
if this hack is not implemented). This method exists and is described
on some of the Joomla! website.

If a) or b), this depends on possibilities of the Joomla! system.

2) Fonts. There should be a way how to install PDF fonts. If you use
the freesans font, then your PDF document will have e.g. 300 kb but if
you will use some core font and you will not bind the font into the
PDF document, your created PDF document will have e.g. 18 kb !!! This
can be important for users who know, they will only create PDF
with characters they are included in core fonts. So it should depend
on users which font they will install. The freesans should stay here
as default font.

The system of installing fonts can be following:

a) This can be a part of e.g. com_pdf component but
b) it can work as Plugin Manager, Module Manager, Language Manger too.
In Joomla! system, there can be a Font Manager. For now we can use
this manager for installing PDF fonts. But in the future we can use
this Font Manger for installing CSS fonts. Under CSS fonts I mean
Font-
face in CSS (.otf for standard browsers, .eot for Microsoft browsers).
So it means in the future there can be two groups of fonts: PDF fonts,
CSS fonts

If you want to see, how this feature can work, just install Phoca PDF
under your 1.5. You can see the installing of the PDF fonts (not so
pure as it will be under Font Manager and as it will have own database
table: jos_fonts). You can see possible parameters which can be used
for creating PDF by users.

If this feature is interesting for you and there is a developer who
cares about PDF in Joomla! please let me know. I am ready to help
while creating this feature.



As Jean-Marie has written, TCPDF can do clean PDF documents now, see
examples (click on PDF icon):

- http://www.phoca.cz/demo/phocapdf-demo (standard Joomla! article
with picture and table, core helvetica font used - it reduce the PDF
size to minimum)
- http://www.phoca.cz/restaurantmenudemo/en/daily-menu (document with
table)
- http://www.phoca.cz/restaurantmenudemo/en/beverage-list (document
with table in tables)

If there is some similar PDF behaviour in Joomla! then all 3rd party
developer can produce PDF plugins for their extension

So e.g. VirtueMart component will not care about PDF (VirtueMart code
can be reduced), only PDF Plugin for VM can be done. With this plugin,
the PDF of some product can be created (in admin, in frontend)

About upgrading TCPDF. As you can run the tcpdf without making changes
there (because there can be some extended class of TCPDF e.g. JPDF
extends TCPDF), it is very easy to do upgrades, mostly the core
library will be loaded and if there will be some core developer who
will take care about PDF, there is no problem for him to actualize
TCPDF (if there will be such behaviour in Joomla! 1.5 it could be
actualized 10x because now we have Joomla! 1.5.10 and I think, this is
enough)

Thank you, Jan

infograf768

unread,
May 13, 2009, 3:27:16 AM5/13/09
to Joomla! CMS Development
This makes sense, Jan.
I do not see though how TCPDF can use normal fonts (what you call CSS
fonts)
> -http://www.phoca.cz/demo/phocapdf-demo(standard Joomla! article

Jan (Phoca)

unread,
May 13, 2009, 5:07:55 AM5/13/09
to Joomla! CMS Development
If I speak about fonts, I speak about 3 types of fonts:

:: 1) standard utf-8 font (e.g. freesans) which can be used in
document. This font is included in PDF document, so it can display
utf-8 characters. This inclusion has disadvantages too, because the
final PDF document will be too large. But for utf-8 languages
(characters with diacritics) this is only one solution.

:: 2) standard font (like helvetica, times, etc.). These fonts are not
included in PDF document. It means, that if user want to see the PDF,
the PDF document will try to find some similar font in user's OS and
will use this. The advantage is, such PDF is small (1 PDF page with
utf-8 font = cca 300 kb, 1 PDF page without embeded font = cca 20 kb),
the disadvantage is, the output of PDF depends on user's OS, so e.g.
it cannot be used for documents with diacritics. But it can be used
e.g. for English language (so if you know, your output is in English
and there are not used special characters, your site can produce PDF
documents which will be not so large)

The goal of some Font Manager (like Plugin or Module manager) should
be, user will install own font (with help of utils included in TCPDF
ZIP you can create own font package too). So user will decide, which
font will be used (if some embeded or not) and will decide how large
PDF documents will be.

If there is some Font Manager in Joomla!, it can be used for CSS fonts
too.

:: 3) CSS Fonts - Under CSS fonts I mean font-face in CSS (.otf for
standard browsers, .eot for Microsoft browsers). Font-face is a
feature of CSS (on some browsers - CSS2, on others CSS3). This is not
related to PDF but to HTML(CSS) site! Now you can set some font family
in your CSS, but the font, which will be used on your site, will be
taken from user's OS (e.g. you set Arial but user doesn't have Arial
in OS installed, so instead of Arial the Serif will be used). With
font-face feature you can load your own font into the site, so it
means not user's OS font will be used but font which is stored on your
server. Why I speak about font-face here? Because if there will be
some Font Manager in Joomla!, then it can be used for two functions:
a) installing PDF fonts (used in PDF documents)
b) installing CSS fonts (used in CSS (HTML) site)

Chris Davenport

unread,
May 13, 2009, 5:38:15 AM5/13/09
to joomla-...@googlegroups.com
Ji Jan,

Couple of questions:

1. Does TCPDF support font subsetting?  That would substantially reduce file sizes even when using freesans.

2. How do you propose handling different pages having different sets of the available fonts?

Chris.


2009/5/13 Jan (Phoca) <phoca.cz@gmail.com>

Jan (Phoca)

unread,
May 13, 2009, 7:10:07 AM5/13/09
to Joomla! CMS Development
Hi,

:: 1) I think not. If you set, your PDF document will include some
font, it must include it all. But the size of PDF document depends on
used font. So e.g. if you don't include font, the size of PDF document
will be smallest. If you need to include some font (because your
language uses diacritics e.g.) you can set your own and affect the
size of PDF document.

Example:

On some of my Czech site I use PDF. Czech uses diacritics, so if I
use:
1) helvetica (not embeded font), my PDF document will have 43 kb (but
without needed diacritics)
2) freesans (embeded font with utf-8 support), my PDF document will
have 530 kb
3) some Czech font (embeded font with utf-8 support but only with
Czech diacritics), my PDF document will have 215 kb.

It means, the size of PDF document depends on used font and if you
have some Font manager, you can install your own font and in fact you
can set the size of outputed PDF document.

:: 2) If there will be plugins for different components, you can set
different fonts for different components. So e.g. if there will be
some plugin for com_content, all articles in Joomla! will use font
selected for com_content, but you can use different font for some
other component. Sure, you can do some "luxus" option and add new
parameter for every article, so you can select font for every article
in your Joomla!. But I think it is not necessary. The goal of choosing
font is choosing it for whole Joomla! site (or for different
components).

The goal is not, user will set Font A for Article A and Font B for
Article B (or Font A for footer of Article, Font B for header of
Article, etc ...). The goal is:

1) Design issue - you will install font you like for all your PDFs
created in your Joomla! site (or for components)
2) Size issue - you will install font which includes characters you
need (if your site is in English, you need not to use freesans which
includes a lot of unnecessary diacritics characters, if you are
running some site in German language, you need some font with ä, ö, ü,
ß, if you are running multi language site, you will install freesans
with all the characters you need)

If we are speaking about CSS font, this can be used for templates.
Template developers can offer template + font. Now some template
developers don't release template packages only but specific modules
which are bundled with the template. So in the future, the template
package can contain template, module, font, ... I think, when font-
face feature will be suported by most used browsers, this feature
should be solved. On template level (specific font for specific
template) or on Joomla! level (specific font for every template you
want)

infograf768

unread,
May 13, 2009, 7:47:45 AM5/13/09
to Joomla! CMS Development
I suggest we forget about Dynamic fonts (what you call CSS fonts) as
this is not working well (depends on platforms/browsers) even when not
considering pdf, but just plain simple sites. Also, these fonts may be
quite heavy, as much in fact as some tcpdf fonts.
As far as I can see, they would also require a way to be transformed
to be used in tcpdf.

Concering the use of basic OS fonts, tcpdf 4.3 ships with
Courrier, Helvetica, Times, Symbol and Zapfdingbats (+ a few exotic
ones) which are indeed lightweight.
Only Latin1 glyphs are included.
These fonts are coded as php. The exotic ones would be worth testing
btw.

As of now, the pdf font used to make a pdf in Joomla native is the
font parametered in the site language xml file.

Phoca

unread,
May 13, 2009, 8:14:34 AM5/13/09
to joomla-...@googlegroups.com
"I suggest we forget about Dynamic fonts (what you call CSS fonts) as
this is not working well"

... the idea was, if there will be some Font Manager in Joomla! then it can be used for dynamic fonts in future too (it means when the support for dynamic fonts will be a standard). There can be two types of fonts (one type for PDF, one for CSS like you have system plugin and content plugin) So CSS fonts need not to be transformed to PDF, they will be used only in CSS (HTML) ... only idea for future usage of Font Manager

"Courrier, Times, Symbol and Zapfdingbats" ... these fonts must not be included in core package.

E.g. only freesans (utf-8) and Helvetica should be included in core Joomla! package. The other fonts can be installed in font manager (like plugins). So the idea is to have some font list, where you get all necessary information (font name, which glyphs are included).

Installation xml can look like:

<install type="pdffont" version="1.5" >
    <name>Dejavu Sans</name>
    <tag>dejavusans</tag>
    <creationDate>01/01/2009</creationDate>
    <author>Author</author>
    <authorEmail>Author Email</authorEmail>
    <authorUrl>Author Site</authorUrl>
    <copyright>Copyright</copyright>
    <license>http://www.gnu.org/licenses/gpl-2.0.html GNU/GPL</license>
   
    <authorFont>see dejavu_AUTHORS.txt file in this package</authorFont>
    <copyrightFont>see dejavu_AUTHORS.txt file in this package</copyrightFont>
    <licenseFont>see dejavu_LICENSE.txt file in this package</licenseFont>
   
    <description>Dejavu Sans Font for Joomla! CMS</description>

    <files>
          <filename>dejavu_AUTHORS.txt</filename>
          <filename>dejavu_LICENSE.txt</filename>       
          <filename>dejavusans.php</filename>
          <filename>dejavusans.z</filename>
          <filename>dejavusans.ctg.z</filename>
          <filename>dejavusansb.php</filename>
          <filename>dejavusansb.z</filename>
          <filename>dejavusansb.ctg.z</filename>
          <filename>dejavusansbi.php</filename>
          <filename>dejavusansbi.z</filename>
          <filename>dejavusansbi.ctg.z</filename>
          <filename>dejavusansi.php</filename>
          <filename>dejavusansi.z</filename>
          <filename>dejavusansi.ctg.z</filename>
          <filename>index.html</filename>
    </files>
</install>




2009/5/13 infograf768 <infog...@gmail.com>

Hannes Papenberg

unread,
May 22, 2009, 2:55:28 PM5/22/09
to joomla-...@googlegroups.com
Hello folks,
in the time that this discussion lasted, TCPDF released not one, not
two, but 15 new versions...

We still have the problem, that Joomla actually does not really support
this PDF feature properly and all the arguments that have been stated
here earlier, still apply. Besides that, Phoca has a better PDF solution
than is currently in the core. However, we also see people wanting to
keep this feature. For those people, I'd like to propose that we remove
it, but provide a sample implementation from the core team, which you
can install to get back that functionality and to show third party
developers how to do this.

This would mean that Joomla still will have this feature as an
extension, but it will also mean that it wont really be developed after
the Joomla code is mostly bug free once. As was said earlier, we'd see
this more as a task or feature for third party developers and thus would
only once provide such a sample implementation and then expect other
developers to pick up from there.

I'd like to hear from you, if that would be acceptable. Of course the
difference between 1.5 and 1.6 with installed PDF feature should only be
obvious to the really trained eye. :-)

Looking forward to your responses.

Hannes

Leftfield schrieb:
> For me, it was sad enough with: "6. Joomla users expect this feature."
> PDF function is/was so much standard feature that i can't image Joomla
> without it.
>
> On Apr 14, 6:15 pm, infograf768 <infograf...@gmail.com> wrote:
>
>> Not sure I agree with this.
>> A few remarks:
>>
>> 1. Last version of tcpdf has really much evolved since the older
>> version we have in 1.5 (last version is 4.5) and it is only (library +
>> freesans fonts) a bit more than 500k tgz
>> 2. Yes, the library is updated frequently, but of concern to us are
>> only major versions (i.e. 2, 3, 4 ). Also, the developper (Nicolas
>> Asuni) is very responsive and any suggestions we would do would be
>> listened to and implemented.
>> Btw, we have the same issue with TinyMCE. We are just starting
>> discussing updating to Tiny 3.
>> 3. The most important "bug" is IE7 pdf display (there is a solution in
>> doc.joomla by Mark) which is NOT tcpdf related, but a Micro$oft issue.
>> 4. A more current issue happens when there is local formatting in
>> content, defining font-family, a bad habit anyway.
>> In this case tcpdf chokes because it does not find the font. A good
>> help and some overlibs should document this better.
>> 5. No one has really tested (unit-test) last versions. My non-unit-
>> tests show here a real improvement on most aspects (Tables, RTL,
>> specific multibytes languages).
>> 6. Joomla users expect this feature.
>> 7. The only 3rd party solution I know of and which is not commercial
>> (Phoca PDF) installs OK here but I can't get it to work on a 1.5.10
>> or earlier. It has still been in alpha stage for months.
>> 8. Plugins do not work in 1.5 pdf because it is not implemented in
>> view.pdf.php
>>
>> JM
>>
>> On Apr 14, 12:38 pm, Lukas Polak <polak.luka...@gmail.com> wrote:
>>
>>
>>> This isn't exactly true, because they have an option to install third
>>> party library for it, what, after all, they did many times because
>>> actuall pdf library has to be updated almost every month to keep it as
>>> much functional as it is possible, so therefore I don't problem with it.
>>>
>>> elf
>>>
>>> Bojan wrote / napísal(a):
>>>
>>>> I agree as well with dropping the PDF Functionality in the joomla 1.6 it
>>>> is clunky and not as usefull, but please note that a lot of people are
>>>> used to having PDF on their sites, it would most certainly cause a big
>>>> array of panic and confusion among the administrators that are not so
>>>> well familiar with the production of joomla, and do not read the changelogs.
>>>>
>>>> Bojan.
>>>>
>>>> Lukas Polak wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I definitely agree with this. After what I've seen, PDF functionality
>>>>> should be yield to third party community, which have more time to
>>>>> mainterance the current working version of it and you, guys, can focus
>>>>> on more serious issues and features for joomla. that's mine opinion.
>>>>>
>>>>> elf
>>>>>
>>>>> Ercan Özkaya wrote / napísal(a):
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> As you can see on the roadmap for 1.6, PDF functionality is to be
>>>>>> examined and dropped if necessary. We wanted to ask about what people
>>>>>> think for leaving this feature to third party community.
>>>>>>
>>>>>> First my reasons for wishing to drop that from core:
>>>>>> 1- It's not a very needed feature anymore to have a pdf for each
>>>>>> content item on your site.
>>>>>> 2- It was a maintenance nightmare in 1.5 (Try searching for pdf in 1.5
>>>>>> tracker:http://tinyurl.com/35xr9x)
>>>>>> 3- The library itself is updated very often and we can't just update
>>>>>> it for each maintenance release we do.
>>>>>> 4- It does not work very good anyway at the moment. You can't use
>>>>>> plugins on it for example.
>>>>>>
>>>>>> We could keep support for PDF document type in JDocument if necessary
>>>>>> and it would be very easy to create a third party component for this.
>>>>>> And we also get rid of about 1 mb in package size after dropping this.
>>>>>> A nice gain.
>>>>>>
>>>>>> So what do you think?
>>>>>>
> >
>
>

Jan (Phoca)

unread,
May 22, 2009, 3:23:59 PM5/22/09
to Joomla! CMS Development
Hallo Hannes,

"As was said earlier, we'd see
this more as a task or feature for third party developers and thus
would
only once provide such a sample implementation and then expect other
developers to pick up from there."

In this case there must be solved two tasks:

- how to let third party developer install new document in Joomla!
(now documents are situated in libraries/joomla folder which is mostly
not accessable while installation some third party component). Not
sure if pasting some new document outside this folder is good
solution :-(
- how to add icons (pdf icon) above the article - whith help of some
system plugin? maybe solving this will be not so easy :-( )

Hannes Papenberg

unread,
May 22, 2009, 4:05:06 PM5/22/09
to joomla-...@googlegroups.com
Hi Jan,
installing a new document type would not be a big problem. Anthony
recently described how to do this in a blog entry on
community.joomla.org with a plugin. This is already possible at this
moment in 1.5. However I'd just use the raw document type and respond
correctly. Then you would use your own component to render the data.

In terms of the icons: It is already planned to move those to plugins
and make this a part of the new JContent class. So basically you could
add whichever buttons you want. There are so much more possibilities
with this. For example instead of generating the PDF on the fly, you
could attach a pre-rendered PDF to such a button. Or you add a "report
this" button to the article or something like that. :-)

Hannes

Jan (Phoca) schrieb:

Phoca

unread,
May 22, 2009, 6:22:42 PM5/22/09
to joomla-...@googlegroups.com
Ok, thank you for this info

2009/5/22 Hannes Papenberg <hack...@googlemail.com>

Ercan Özkaya

unread,
May 23, 2009, 5:51:11 AM5/23/09
to Joomla! CMS Development
Hi Jan,

What exactly do you need a new document type for? Raw type can be used
as Hannes said but we can keep pdf document type if needed and we can
discuss what is needed to make it generic and re-usable by any pdf
generator.

On May 23, 1:22 am, Phoca <phoca...@gmail.com> wrote:
> Ok, thank you for this info
>
> 2009/5/22 Hannes Papenberg <hackwa...@googlemail.com>

Hannes Papenberg

unread,
May 31, 2009, 7:38:43 PM5/31/09
to joomla-...@googlegroups.com
This feature has now been completely removed. We would be happy, if
someone would take up the challenge of creating a component and the
necessary plugins to implement this again as an installable feature,
that would be presented on joomla.org as a sample implementation. Maybe
you want to start a big PDF component that goes way further than the
current feature? Provide the sample implementation and develop your
extension further from there. We're waiting for your proposals. :-) If
you want to talk about how this could be best implemented, just reply
and we will happily provide you with a basic sketch up on how this could
be done.

Hannes

Ercan Özkaya schrieb:

JM Simonet

unread,
Jun 1, 2009, 2:01:20 AM6/1/09
to joomla-...@googlegroups.com
Hmm... I am really sorry this decision was taken,
although it was to be expected from the beginning
at looking at the posts above.

What about the status of that component. I mean
will it be free as in free beer?
If it is not, are we not providing by this
decision a niche for a commercial-only solution,
i.e. getting users even more frustrated?

As tcpdf is anyway the only solution, shall we
keep the tags for the pdf font in the language
xml as well as a folder for fonts in the site
language folder?
Otherwise the interface of that "eventual" 3pd
component would have to provide a choice of fonts
per language in the admin (or, better, per
article).

** What would really help anyway is to implement
the language field in the tables as a priority.

JM
--
Merci de ne pas renvoyer de pièces attachées automatiquement.
------------------
Jean-Marie Simonet/infograf

info...@orange.fr
http://www.info-graf.fr

Reply all
Reply to author
Forward
0 new messages