Hello. I'm using Fop 1.0 to create reports in Java and print
(MimeConstants.MIME_FOP_PRINT) or view (MimeConstants.MIME_FOP_AWT_PREVIEW)
them.
I've been using Fop 1.0 with Windows XP and 2000 and everything worked
perfecty. Now I upgraded to Windows 7 and Vista and the same configuration
and
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:
Hi Ulrich,
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. But if your font is located at
directory of
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
Hi all,
It looks like Apache FOP does not yet support ePub [1] as a target output
format [2]. Does anyone know if this format could even be a possibility?
If it is what are peoples general interest in this format? If there is enough
interest could it maybe be considered to at least go on the
I thought ePub was just straight XML (okay XHTML) and a zip archive and not
something on the lines of PDF which requires a tool such as FOP. So all you
would require is a XSLT and appropriate rules to create ePub and then zip it.
Am I wrong on what I just read at the Wikipedia link?
Marijan
Sorry forgot the manifest and metadata.
Marijan (Mario) Madunic
Publishing Specialist
New Flyer Industries
-Original Message-
From: Mario Madunic
Sent: Thursday, April 14, 2011 6:16 AM
To: fop-users@xmlgraphics.apache.org
Subject: RE: Output to ePub format
I thought ePub was just
Hi, Ulrich-
I took another look at my configuration and wanted to clarify. I ended
up using absolute paths for the embed-urls because the font files were
in a different directory than the metrics files.
However, I did have to place the font-base tag at the top level in the
configuration
Hi,
Relative font path works for me on embed-url attribute (Windows + JDK
6.0.20), whatever FOP version (0.95, 1.0, or TRUNK):
Either on my dev machine (invoking FOP via CLI):
snip
font-basefile:///D:/fonts/font-base
font kerning=yes embed-url=dejavu/DejaVuSans.ttf.../font
/snip
Or in
Hi FOP experts,
I hope you can help me with my problem.
As I understand from the specification and previous posts, an inline with
keep-together.within-line=always should prevent hyphenation of the
containing text by ensuring that it is rendered on the same line. But that
does not seem to work
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:
On 14 Apr 2011, at 17:15, Ulrich Mayring wrote:
Hi Ulrich
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.
In
On 14 Apr 2011, at 17:28, Andreas L. Delmelle wrote:
In that case, can you check what happens if you use
a trailing slash in the embed-url?
^^
Errmm... Sorry, too quick. I obviously meant 'the font-base'.
Regards
Andreas
---
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
On 14 Apr 2011, at 15:14, Tobias Rettstadt wrote:
Hi Tobias
As I understand from the specification and previous posts, an inline with
keep-together.within-line=always should prevent hyphenation of the
containing text by ensuring that it is rendered on the same line. But that
does not seem to
hi,
i want do emped a lot of jpg-files into a dokument. my position starts
at x=0mm and y=0mm
after generating the pdf-file for all images is a offset of y=+1.2mm.
if i change the reference-orientation from 0 to 180 (mad) the positon is
korrekt.
my fop-file
...
fo:root
Hi Tobias,
a possible workaround for this bug is to wrap every text character in a
fo:character element and set its hyphenate attribute to false.
Here is a XSL example for doing that:
xsl:template match=text() mode=join
xsl:call-template name=doJoin
xsl:with-param name=text select=string(.)/
17 matches
Mail list logo
