The DOMPDF team is happy to announce the availability DOMPDF 0.6.0
alpha 2. You can find the download of this pre-release on the code
site at http://code.google.com/p/dompdf/downloads.
No doubt you've noticed the new version number assigned to this
release. We felt that the number of features added since 0.5.1
sufficiently justified this change. Here is a quick breakdown of the
modifications made since the previous alpha release:
- basic Unicode support is now available
- full Windows ANSI character set support when not using Unicode
- bug fixes for debugging (Issue 57), the image cache (issue 17,63),
and inline-table styling (Issue 34)
A note about Unicode support. While this feature is functional it is
not yet finalized, so there are a few bugs yet to be worked out.
However, If you abide by the following guidelines you should be O.K.:
1) You must provide your own TrueType font (OpenType fonts are not
currently supported). This means that you must use the load_font.php
script to add a new font to DOMPDF. If you're not familiar with the
procedure please read the relevant section on the wiki (http://
code.google.com/p/dompdf/wiki/Installation). The wiki needs quite a
bit of updating, but it still provides a good overview.
2) Related to the above, you must use the modified version of ttf2pt1
(called ttf2ufm) included with this distribution. Binaries have been
provided for both linux and Windows (though not fully tested for
either system). Full source code is also available if the binaries do
not work. (If you compile your own copy the resulting binary will be
called ttf2pt1.)
3) Ensure that the font you provide is applied to all content of the
document. That means you should style the body tag to use this font.
If you do not do this you may have some random white space which will
use the default font, which could result in PDF errors.
4) Do not use the core fonts when Unicode is enabled. These fonts do
not currently work and if you attempt to use them you will get PDF
errors when the document is opened. (This is the reason for the above
guideline.)
Please note that since this is an alpha release, we can't offer any
assurances that it is stable enough for production environments.
Though informal testing on our own systems shows the code to perform
at least as well as DOMPDF 0.5.1, we highly recommend that you perform
sufficient testing to ensure that the code meets your requirements if
you decide to implement on a public site.
Thank you all for your support and patience as we move forward.
Hi, i'd like to ask a question, and i excuse if it's not the right
place to ask, but i'd like to know if in version 0.6 alpha is png
alpha channel supported, and why was not supported in previous
versions.
It's a platform limitation (like no alpha channel for embedded images
in pdf, and the whole process should get through rasterization) or
some other weird reason ?
On Nov 25, 7:43 pm, LiFeleSs <lifeles...@gmail.com> wrote:
> Hi, i'd like to ask a question, and i excuse if it's not the right
> place to ask, but i'd like to know if in version 0.6 alpha is png
> alpha channel supported, and why was not supported in previous
> versions.
> It's a platform limitation (like no alpha channel for embedded images
> in pdf, and the whole process should get through rasterization) or
> some other weird reason ?
This is as good a place as any to pose this question. Currently DOMPDF
does not support alpha transparency in PNG images. I personally
haven't done much work with the image support in DOMPDF (Benj and
Helmut did most of the work in this area), but a quick perusal of the
code and a search of the web leads me to believe that raster image
(GIF, PNG, TIF) transparency is just not supported in the version of
the PDF spec utilized by DOMPDF (1.3).
Later versions of the spec do include transparency options, but until
we take care of some of the outstanding and fairly significant issues
we won't be looking to support newer versions of the spec. I can see a
possible work-around for us in the current spec by using masks. We
wouldn't be able to natively support transparency, but we might be
able to fake it by masking out the areas that should be transparent.
I'm not even sure if using masks to fake transparency is a valid idea
right now because I haven't done much research on the matter, and for
all I know it could wind up looking horrible. But I'll be sure to add
it to the list of things to research.
> On Nov 25, 7:43 pm, LiFeleSs <lifeles...@gmail.com> wrote:
> > Hi, i'd like to ask a question, and i excuse if it's not the right
> > place to ask, but i'd like to know if in version 0.6 alpha is png
> > alpha channel supported, and why was not supported in previous
> > versions.
> > It's a platform limitation (like no alpha channel for embedded images
> > in pdf, and the whole process should get through rasterization) or
> > some other weird reason ?
> This is as good a place as any to pose this question. Currently DOMPDF
> does not support alpha transparency in PNG images. I personally
> haven't done much work with the image support in DOMPDF (Benj and
> Helmut did most of the work in this area), but a quick perusal of the
> code and a search of the web leads me to believe that raster image
> (GIF, PNG, TIF) transparency is just not supported in the version of
> the PDF spec utilized by DOMPDF (1.3).
> Later versions of the spec do include transparency options, but until
> we take care of some of the outstanding and fairly significant issues
> we won't be looking to support newer versions of the spec. I can see a
> possible work-around for us in the current spec by using masks. We
> wouldn't be able to natively support transparency, but we might be
> able to fake it by masking out the areas that should be transparent.
> I'm not even sure if using masks to fake transparency is a valid idea
> right now because I haven't done much research on the matter, and for
> all I know it could wind up looking horrible. But I'll be sure to add
> it to the list of things to research.
On second thought, if we were to implement masking the results would
be more akin to indexed transparency (as in GIF images) rather than
full alpha channel transparency ... so it really would not look all
that great.
> The DOMPDF team is happy to announce the availability DOMPDF 0.6.0 > alpha 2. You can find the download of this pre-release on the code > site athttp://code.google.com/p/dompdf/downloads.
> No doubt you've noticed the new version number assigned to this > release. We felt that the number of features added since 0.5.1 > sufficiently justified this change. Here is a quick breakdown of the > modifications made since the previous alpha release:
> - basic Unicode support is now available > - full Windows ANSI character set support when not using Unicode > - bug fixes for debugging (Issue 57), the image cache (issue 17,63), > and inline-table styling (Issue 34)
> A note about Unicode support. While this feature is functional it is > not yet finalized, so there are a few bugs yet to be worked out. > However, If you abide by the following guidelines you should be O.K.:
> 1) You must provide your own TrueType font (OpenType fonts are not > currently supported). This means that you must use the load_font.php > script to add a new font to DOMPDF. If you're not familiar with the > procedure please read the relevant section on the wiki (http:// > code.google.com/p/dompdf/wiki/Installation). The wiki needs quite a > bit of updating, but it still provides a good overview. > 2) Related to the above, you must use the modified version of ttf2pt1 > (called ttf2ufm) included with this distribution. Binaries have been > provided for both linux and Windows (though not fully tested for > either system). Full source code is also available if the binaries do > not work. (If you compile your own copy the resulting binary will be > called ttf2pt1.) > 3) Ensure that the font you provide is applied to all content of the > document. That means you should style the body tag to use this font. > If you do not do this you may have some random white space which will > use the default font, which could result in PDF errors. > 4) Do not use the core fonts when Unicode is enabled. These fonts do > not currently work and if you attempt to use them you will get PDF > errors when the document is opened. (This is the reason for the above > guideline.)
> Please note that since this is an alpha release, we can't offer any > assurances that it is stable enough for production environments. > Though informal testing on our own systems shows the code to perform > at least as well as DOMPDF 0.5.1, we highly recommend that you perform > sufficient testing to ensure that the code meets your requirements if > you decide to implement on a public site.
> Thank you all for your support and patience as we move forward.
A few people who are unfamiliar with how to use Subversion have expressed interest in trying out the latest version of the code. With that in mind I have set up a page that will let you grab the latest revision. I haven't optimized the code that does this, so the download is a bit slow to start.
Please note: if you are interested in trying out the latest development code you should only do so after you have performed sufficient testing ... more so een than with the alpha release. This code has not necessarily been run against the full set of test files, so there may be some issues that haven't been caught.
Sorry but I don't understand your tutorial about Unicode support.
I use the symfony plugin. Everything works well but I have to manage a new language, Russian and I have strange characters in the PDF. I got the last version of dompdf (alpha 0.6 beta 2) because I saw Unicode support. I used the load_font.php, ttf2ufm, etc... I finished to get a lot of files (Helvetica.z, Helvetica.ctg.z, Helvetica.php) but I don't understand where I have to put them (in lib/fonts ?) and do I need to load this font in my code or is it automatic (just need to define font in my html ?) ?
On Feb 17, 8:40 am, rja <rja...@hotmail.fr> wrote:
> Sorry but I don't understand your tutorial about Unicode support.
> I use the symfony plugin. Everything works well but I have to manage a > new language, Russian and I have strange characters in the PDF. I got > the last version of dompdf (alpha 0.6 beta 2) because I saw Unicode > support. I used the load_font.php, ttf2ufm, etc... I finished to get a > lot of files (Helvetica.z, Helvetica.ctg.z, Helvetica.php) but I don't > understand where I have to put them (in lib/fonts ?) and do I need to > load this font in my code or is it automatic (just need to define font > in my html ?) ?
> Thanks for your work and your answer.
load_font.php should take care of placement for you. I'm not sure where the files you have came from because load_font.php should produce only *.afm and *.ufm files based on your TrueType font file. Can you outline the steps you took?
