gt;
> -Original Message-
> From: Ulrich Mayring [mailto:u...@denic.de]
> Sent: 06 March 2018 16:09
> To: fop-users@xmlgraphics.apache.org
> Subject: Ideas needed: insert byte[] into XSLFO
>
>
>
> Hi all,
>
> I have a byte[] (basically, a PNG or JPG image
Hi all,
I have a byte[] (basically, a PNG or JPG image) that I generated myself
and would like to insert it in an XSLFO page at a certain position and
render the page to PDF with fop.
Think of it like a letter with a logo, only that the logo is dynamically
created.
The best way to insert it
Furthermore, the cost of not having automated tests for your PDF generation
eclipses any other cost mentioned so far.
If I were a banker and my IT guy told me he can't upgrade a library, because
he does not have automated tests... hmm :)
Ulrich
Rob Sargent wrote:
Furthermore, the cost
aspect of using an unreleased version. You
have to spend more effort to use it, but you gain from its new features,
fixes, etc.
Regards,
Glenn
On Fri, May 31, 2013 at 1:36 AM, Ulrich Mayring u...@denic.de wrote:
Oh, and another thing: the new code depends on an unspecified trunk
version
%3e
On Wednesday, May 29, 2013, Ulrich Mayring wrote:
Ooops, the newest Nightly Build has changed the Interface of FopFactory
and FontManager. All the setter-methods in those classes are gone. How can
I programmatically configure FOP now? The docs under
http://xmlgraphics.apache.org/**fop/trunk
nightly build, so
that everyone downloading fop-trunk is on the same page with respect to
external dependencies.
Kind regards,
Ulrich
Ulrich Mayring wrote:
Hello Luis,
the problem with this approach is that not all setter-methods that were
available in FopFactory are now available
Hi all,
please find attached an FO file and two PDFs, which were rendered from it.
One was rendered by FOP 0.95, while the other was rendered by FOP 1.1.
If you compare the PDFs, you'll see that the header Price (EUR) as well as
the value 8,888,888.88 jut out to the right in the FOP 1.1
if
you don't want to build yourself). There were some fixes in this are since
1.1.
On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de wrote:
Hi all,
please find attached an FO file and two PDFs, which were rendered from it.
One was rendered by FOP 0.95, while the other was rendered
way.
cheers,
Ulrich
Ulrich Mayring wrote:
Hi Glenn,
thanks for the pointer, your suspicion was correct. With the latest nightly
build the page is rendered like it was in FOP 0.95, which I believe is the
correct way.
Thanks a lot,
Ulrich
Glenn Adams wrote:
I would suggest you check
Apparently the setter methods were deleted by merging a Temp_URI_Unification
branch back into the trunk. Unfortunately I can't find this branch in the
repository. Also, the supplied examples never configure the FopFactory
programmatically.
Ulrich
Ulrich Mayring wrote:
Ooops, the newest
Hi all,
I just upgraded from 0.95 to 1.1 and one of the issues that crept up is that
suddenly FOP uses ligatures, which it did not use before. Latin words
containing the letters fi or fl are now rendered using ligatures in the
PDF, although they are written as two seperate characters in the
Vincent Hennebert wrote:
Hi Ulrich,
On 28/05/13 11:01, Ulrich Mayring wrote:
Hi all,
I just upgraded from 0.95 to 1.1 and one of the issues that crept up is that
suddenly FOP uses ligatures, which it did not use before. Latin words
containing the letters fi or fl are now rendered using
Ulrich Mayring wrote:
Vincent Hennebert wrote:
Hi Ulrich,
On 28/05/13 11:01, Ulrich Mayring wrote:
Hi all,
I just upgraded from 0.95 to 1.1 and one of the issues that crept up is that
suddenly FOP uses ligatures, which it did not use before. Latin words
containing the letters fi or fl
], or, more generally, the
font-feature-settings property [3] as fox: extension attributes.
[2] http://www.w3.org/TR/css3-fonts/#font-variant-ligatures-prop
[3] http://www.w3.org/TR/css3-fonts/#font-feature-settings-prop
Regards,
Glenn
On Tue, May 28, 2013 at 3:01 AM, Ulrich Mayring u
Terence M. Bandoian wrote:
Hi, Ulrich-
That matches my experience with 1.0. Setting font-base works with
metric-url but I've used absolute paths for embed-url.
So then it appears to be a bug. I'll report it.
Ulrich
--
View this message in context:
mehdi houshmand wrote:
Sorry for the late reply, but /my/font/path isn't a reference to a
relative path. That's an absolute path. If the absolute path of your
font were /my/font/path/myfont.ttf, then your config is correct, and
you are right in issuing a bug.
Mehdi,
I think I know the
Hm, maybe it's not a problem with the FOP code itself, but with the new
version of xmlgraphics-commons included in FOP 1.0. At least there seems to
be a new class called CommonURIResolve involved, which wasn't used in FOP
0.95.
Ulrich
--
View this message in context:
I already tried the trailing slash yesterday, when you first suggested it.
However, I had to change the code of our application for that, as it doesn't
honor the setting in fop.xconf normally. The result was the same, though.
Normally our application sets the font path programmatically and it
mehdi houshmand wrote:
Hi Ulrich,
Have you tried setting the font-base in your fop.xconf? I must admit I
haven't used the API much but you can set the font-base by inserting
following in the fop.xconf:
font-base ** the base directory ** /font-base
Hi Mehdi,
we have set the font-base
I have tried both suggestions, using a file-url and appending a slash, but to
no avail.
Please keep in mind that this is a regression, i. e. not I am doing
something wrong, but something changed from fop 0.95 to fop 1.0. Take
another look at the error message:
Failed to resolve font with
Pascal Sancho wrote:
Hi Ulrich,
I have no solution, only questions:
- Are the 2 FOP versions run on the same host?
- What OS do you experiment?
- Have you tried direct access to /path/to/fonts + / + myfont.ttf
(either with ls or dir) ?
- Does FOP 1.0 load the right fop.xconf
Michonska Sylvie wrote:
Hi Vincent,
Thanks for your response.
But I want to change to FOP 0.94 (or 0.95) to transform XML files en PDF/A files
(this isn't possible with FOP 0.20.5).
We use FOP in a progiciel to edit dynamic documents.
Our clients use our progiciel to edit or send letters or
Hi all,
I am getting a warning in FOP 0.95:
xHeight value could not be determined. The font may not work as expected.
Am I correct in assuming that may not work as expected applies only to sub-
and superscript or are there other caveats? The font in question is a
Dingbats font.
Kind
Peter Coppens wrote:
I struggled with something similar
See http://markmail.org/message/5ppuwom7arnzqjy7
The solution provided was to set font-size=0pt
I changed my FO according to your example:
fo:block-container absolute-position=fixed left=0.5cm top=10cm
height=1cm width=0.5cm
Pascal Sancho wrote:
I think that your problem is related to an auto-scale option.
I suggest that you check if such option is checked in the printing panel of
your PDF viewer.
You're right and I'm stupid - the setting had no effect in my test file
because of scaling. In my original file the
Jeremias Maerki wrote:
The TextLayoutManager currently always retrieves the width of the hyphen
(and space) glyph instead of doing lazy initialization. Patches to
improve things like that are welcome.
Ok thanks, will try to contribute, once I get my head around this stuff :)
Looks like
Hi folks,
since upgrading from FOP 0.20.5 to 0.95 the positioning of my SVG elements
changed. In my FO I am basically doing this:
fo:block-container position=absolute left=0.5cm top=20cm height=1cm
width=0.5cm
fo:block
fo:instream-foreign-object
svg:svg height=0.5cm width=0.5cm
Jeremias Maerki wrote:
Looking at the default configuration file in 0.20.5 we did indeed have
ascii-85 in the filter list. But since most people care more about file
size than readability in a text editor, our current default without the
ascii-85 filter is probably better.
Agreed and I wish
I am getting this when using a Dingbats font and rendering to PDF:
WARNING: Substituted specified hyphenation character (0x2d) with 0x20 because
the font doesn't have the specifiedhyphenation character: Dingbats,normal,400
Kind of weird, since the line is very short and hyphenation seems
Jeremias Maerki wrote:
No, you need the AFM and PFM but you don't need the XML file generated
by PFMReader. Actually PFMReader, as the name says, can only read the
PFM file, but without the XML font metrics file, FOP can actually read
the AFM, too, and use the more complete metrics information
Jeremias Maerki wrote:
Executive summary: the AFM alone is usually sufficient.
Both AFM and PFM contain a different set of font metrics. For
well-behaved Type1 fonts, the AFM alone is sufficient. When testing I
found at least one font where the PFM provided some information that
wasn't
Jeremias Maerki wrote:
SEVERE: Failed to read font metrics file null
But I'm not convinced that this is a bug. Without the PFM in my hands, I
can't tell.
What I meant is that the error output is buggy. It gives null as the
unreadable font metrics file, which makes no sense. It should give
In FOP 0.94 there is documentation with respect to Dingbats fonts, that the
PFMReader writes UnknownEncoding to the metrics file. This has to be
replaced with SymbolEncoding or ZapfdingbatsEncoding.
The PFMReader from FOP 0.95 now writes WinAnsiEncoding for the URWDingbats
font to the metrics
. a simpler life. I can't
help but be amused about this. ;-) I guess we should consider adding a
big disclaimer to PFM/TTFReader stating that these tools will soon be
obsolete. Any other ideas?
On 09.01.2009 10:52:53 Ulrich Mayring wrote:
In FOP 0.94 there is documentation with respect to Dingbats fonts
Jeremias Maerki wrote:
Currently, FOP uses the default JAXP factories. We talked once about
making this configurable but nobody has taken the time, yet.
I don't think it is necessary to make the factories configurable within FOP,
any user program embedding FOP can do this. Also, the
Hi all,
is there any way to find out programmatically which XML parser and XSLT
transformer Fop is actually using at runtime?
Since Fop uses JAXP, I can of course look up the various factories, but that
won't tell me the actual implementation version being used. Maybe this is
more of a JAXP
Chris Bowditch wrote:
v0.9x is a complete re-write of 0.20.5 so I don't think that is a fair
assumption.
AFAIK the dependency on a graphical environment was due to Batik, so the
complete rewrite of fop may not have any bearing on this issue.
I am guessing that some X libraries weren't
Hi all,
I have recently upgraded my computer to fedora 9 (was fedora core 4) and
suddenly fop doesn't work anymore. The X server is running, but I also tried
the -Djava.awt.headless=true trick, which didn't work either.
Whenever I try to render a page, I am getting this in the logfile:
38 matches
Mail list logo
