Hello,
I have certain elements in my document which I would like to keep
together across pages as much as possible. I've been using the
keep-together (and keep-together.within-column) property for this, and
usually it works as expected: if printing the item on the current page
would cause it to
successfully.
Eric Amick Systems Engineer II
Legislative Computer Systems
-Original Message-
From: Brad Smith [mailto:usernamenum...@gmail.com]
Sent: Tuesday, May 25, 2010 15:03
To: fop-users@xmlgraphics.apache.org
Subject: keep-together.within-column with content 1 page
Hello
It's actually not a problem with margins per se. Remember that the
solution I was working on involved creating a template for section
that caused it to be rendered as a two-column table, the left column
for an optional icon, and the right for the section content. The
problem arises when a nested
I would like to alter my docbook stylesheets so that sections with a
given role are designated by a margin icon. This seems like a place
where figure floats
(http://www.sagehill.net/docbookxsl/FigureFloats.html) would be
appropriate, but apparently fop does not support these. So, I am
looking at
xsl:attribute-set name=monospace.verbatim.properties
xsl:attribute name=wrap-optionwrap/xsl:attribute
xsl:attribute name=hyphenation-character\/xsl:attribute
/xsl:attribute-set
The second attribute hyphenation-character identifies the character to
use when the line is broken, in this
Engineer II
Legislative Computer Systems
-Original Message-
From: Brad Smith [mailto:usernamenum...@gmail.com]
Sent: Tuesday, February 02, 2010 9:54
To: fop-users@xmlgraphics.apache.org
Subject: Is it possible to prevent line breaks on '/'?
Is it possible to prevent fop from
Is it possible to prevent fop from breaking lines on certain
characters? For example, I've got a few places where lines break like
this:
...Instead list the contents of /
mnt/install and...
That looks pretty terrible, and it would be much better if all of
/mnt/install were bumped to the next
To prevent truncated lines, my stylesheets currently have screen,
programlisting, etc map to fo:blocks with wrap-option=wrap. It
would be really nice, though, if locations where line wraps are
inserted could be denoted with some kind of graphic, or even a simple
'\'. I've got a script that can do
Hello all,
I have a document that has notes scattered throughout, which are
presented in little boxes with a light-grey background. The xslfo for
them looks like this:
fo:block
background-color=#ee
margin=10px
padding=10px
padding-bottom=5px
That seem to have worked. Thanks!
On Mon, Sep 22, 2008 at 3:13 PM, Andreas Delmelle
[EMAIL PROTECTED] wrote:
On Sep 22, 2008, at 20:54, Brad Smith wrote:
Hi
snip /
When I print one of these on a color printer, the grey box looks
perfect, but if I print it on a greyscale printer, the box
Hello all,
Fop currently seems to treat '/' and '-' as valid characters for
adding linebreaks within a word. This is problematic for filenames and
command names, as it causes things like the attached, where on line 1
we see a filename split after the initial '/' and on line 2, where a
command is
A simple way to get this would be a fo:inline with a
keep-together=always on it, if FOP implemented this.
Should I take this to mean that FOP does not implement this, so I
shouldn't bother?
A more convoluted work around involves building your own font,
which uses / and - as glyphs for some
to the
change I made.
--Brad
On 1/2/02, Manuel Mall [EMAIL PROTECTED] wrote:
On Saturday 09 June 2007 00:50, Brad Smith wrote:
I'm afraid most of the implementation-level discussion of this is
above me, but I can give you a hint that might prove helpful: our
translator did some experimentation
Ok, that got the package build, but I'm afraid the fix Manuel
suggested does not work.
Here's what I did:
1) Modified src/codegen/unicode/data/LineBreakPairTable.txt (see attached)
2) Ran ant codegen-unicode
3) Ran ant package
4) Rebuilt problem pdf using new fop
Result was the same word-break
I'm afraid most of the implementation-level discussion of this is
above me, but I can give you a hint that might prove helpful: our
translator did some experimentation and found that fop 0.93 breaks
ko-KR correctly, whereas fop trunk does not. On the other hand, 0.93
does not correctly break
I am having an issue with Korean words not breaking properly. I'm
using a fop build based on the svn trunk as of 2007-05-01. The
attached screenshot shows an example, courtesy of our Korean
translator. The blue rectangle on the left shows the text as-rendered,
with each line ending in a mid-word
On 5/11/07, Jeremias Maerki [EMAIL PROTECTED] wrote:
FOP doesn't support font selection character by character, yet. You'll
have to make sure you use a different font for bullets than for the rest
of the text.
Ok, so I am correct that bullet glyphs are provided by the fonts?
Interesting, I
HI all,
One of our Chinese translators has brought up concerns about fop's
rendering that I'm not sure what to do about. Aparently in Chinese,
since all the characters take up the same amount of space, lines
should always be exactly the same width. Uneven lines look very
unprofessional.
The
1. Use a fixed width font in which the western chars have the same width
as the Chinese chars.
Thanks very much for the quick response.
Ok, I get what you're saying, but I haven't dealt much with fonts. Is
there a handy tool (pref for Linux) that will tell me the width(s)
that a given .ttf
Hi everyone,
I've got a document that is being translated into Korean. The problem is
that when we render the Korean translation, the bullets in our
itemizedlist blocks disappear. If I tweak things just enough to make
loading the fonts fail, so that fop falls back on a western font and
replaces
Swapped to a different font (one of the free ones included with
Fedora) and the problem still remains. The document renders fine, with
everything indended as it should be an no aparnent instances of font
glyphs overlapping bullets. There're just... no bullets. =:(
--Brad
On 5/10/07, Brad Smith
instead of calling ant, just say ant package. That will skip all
Thanks. That's what I needed. Just one more dummy-problem: this builds
fop, but I can't find anything on how to build a fop-TTFReader to go
with it. Any help?
--Brad
Hrmm... I see a
build/classes/org/apache/fop/fonts/apps/TTFReader.class, but while a
fop executable is generated in my checkout directory, fop-TTFReader is
not.
--Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
If you could try the current fop trunk that would be good. If you can't
e-mail me directly a testcase together with the fonts you are using and
I'll give it a go.
Hmm.. I can't seem to get the trunk to build (Fedora 6). Ant complains
that some of the junit tests were skipped or failed, but
Hello all,
I have some documents with Japanese text that have been presenting
some very frustrating problems. When I render them using fop, in
several places long lines with no spaces (as is often the case with
such languages) spill over the edge of the page. Some searching online
and on this
Has anyone made an rpm of 0.93? Failing that, I could try and make one
from a source rpm of 0.92, but I haven't been able to find that
either. =:\
--Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
I have seen references on this list to people using fop in conjunction
with java 1.5. However, fop breaks on my system that has it. Now, I
notice that the binary distribution of 0.92beta lists java 1.4
specifically, eg
fop-0.92beta-bin-jdk1.4.tar.gz
Would compiling from source on a java 1.5
Hello,
I am trying to add a script to our pre-processing regimen that uses
the imagemagick tools to automatically resize images that are too
large for the PDFs we generate eg:
convert -resize ${NEW_WIDTH}x $FILE $FILE
for files that are too wide. After resizing a file it looks fine when
28 matches
Mail list logo
