Adrian,
for the same reason I must disagree with the this change: If the fonts
are not available (symbol, zapf dingbats), fop will just fall back to
the default font, where the character is also not available. What you
loose in this case is a little bit of performance. What you gain is the
chance
Hi Andreas,
Just realised that this change broke some units tests... will look at fixing
this.
Adrian.
Andreas Delmelle wrote:
On Jul 17, 2008, at 19:39, [EMAIL PROTECTED] wrote:
Hi Adrian,
Author: acumiskey
Date: Thu Jul 17 10:39:14 2008
New Revision: 677648
URL: http://svn.apache.org/vi
I've been quiet about about this PDF extension so far because I didn't
see much harm in doing it in a generic way for some simple name/value
pairs. If that goes much further (like doing hacks to produce some
complex PDF structures but still forcing it into the generic extension)
then I'm a bit conc
On Jul 17, 2008, at 19:39, [EMAIL PROTECTED] wrote:
Hi Adrian,
Author: acumiskey
Date: Thu Jul 17 10:39:14 2008
New Revision: 677648
URL: http://svn.apache.org/viewvc?rev=677648&view=rev
Log:
ZapfDingbats and Symbol is not always available on the AFPRenderer
so we can't have these as default
On Jul 17, 2008, at 18:53, Jeremias Maerki wrote:
For that you need an "Explicit Destination" (PDF 1.4, 8.2.1,
"[page /Fit]")
which you place as a value for the "OpenAction" key in the "Document
Catalog".
Thanks for the pointer! Unfortunately for Bill, this means that the
patch will need s
For that you need an "Explicit Destination" (PDF 1.4, 8.2.1, "[page /Fit]")
which you place as a value for the "OpenAction" key in the "Document
Catalog".
On 17.07.2008 18:31:13 Andreas Delmelle wrote:
>
> On Jul 17, 2008, at 15:07, Bill Harrelson wrote:
>
> Hi Bill
>
> > Thank you very much! (
On Jul 17, 2008, at 15:07, Bill Harrelson wrote:
Hi Bill
Thank you very much! (in advance).
I have a client that prints labels that we generate with fop to a
pdf file, but the default print settings are "Scale to fit", and
we're printing full bleed, so we need to set PrintScaling to 'None'
I've looked at svnmerge-migrate-history.py and performed the changes
manually on the branch. At least, I can continue now and deal with the
conflicts that appeared anyway. Let's hope my changes don't produce any
problems downstream.
On 17.07.2008 15:15:28 Jeremias Maerki wrote:
> Looks like we sho
Looks like we should think about using SVN 1.5's merge tracking instead
of svnmerge:
http://blogs.open.collab.net/svn/2007/10/subversion-15-m.html
"svnmerge.py doesnt always properly merge merge-properties (like
svnmerge-integrated and svnmerge-blocked), leading to property conflicts
when merging
YAHOO
Message:
BUILD SUCCESSFUL
Total time: 1 minute 7 seconds
Man, I thought it was just me. You guys are the best. Thanks for all the
work.
Whats funny is, I didn't even dive in the FOP source code to work on the
table-continued markers. I almost gave up!
Thanks.
Andreas Delmelle-
Andreas Delmelle schrieb:
> On Jul 16, 2008, at 18:45, Chris Bowditch wrote:
>> Dave of Siemens wrote:
>>> The one
>>> feature that we're anxious to see is indexing support (XSL-FO 1.1,
>>> 6.10). Does anyone know if this is being worked on?
>>
>> Not that I know of. It would indeed be a great addi
I'm trying to merge the latest changes from trunk to the
https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign
branch. But I'm getting the following error:
C:\Dev\FOP\main\xml-fop-temp5>svnmerge merge
svnmerge: command execution failed (exit code: 1)
svn merge -r 675697:
12 matches
Mail list logo
