DOMPDF 0.6.0 alpha 2 now available
BrianS
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.
LiFeleSs
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 ?
BrianS
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.
BrianS
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.
BrianS
> 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
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.
zip format
http://www.eclecticgeek.com/dompdf/nightly.php?format=zip
tar.gz format
http://www.eclecticgeek.com/dompdf/nightly.php?format=tar.gz
rja
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.
BrianS
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?