keep-together.within-column with content 1 page
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 spill over, a page-break is inserted before it. Great. However, there are problems if the item's content is greater than one page in length. In that case, it *still* stays on the same page, even though that means all the content writing over its self, resulting in gibberish. Is there a way to have a middle-ground? What I really want is start on a fresh page if it will keep the item from breaking, then keep together /if possible/. Thanks in advance for any help people can offer. --Brad - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: keep-together.within-column with content 1 page
I've tried both. Same results either way. --Brad On Tue, May 25, 2010 at 3:32 PM, Amick, Eric eric.am...@mail.house.gov wrote: Are you setting just keep-together.within-column? In my experience, the unqualified keep-together (and unqualified keeps in general, for that matter) rarely works 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, 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 spill over, a page-break is inserted before it. Great. However, there are problems if the item's content is greater than one page in length. In that case, it *still* stays on the same page, even though that means all the content writing over its self, resulting in gibberish. Is there a way to have a middle-ground? What I really want is start on a fresh page if it will keep the item from breaking, then keep together /if possible/. Thanks in advance for any help people can offer. --Brad - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- ~ Second Shift: An original, serialized audio adventure ~ http://www.secondshiftpodcast.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: Alternatives to float graphics?
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 section is rendered, because it creates a nested table, so this: section role=something S1 content section role=somethingelse S2 content /section /section renders as: == | | | | S1 icon |S1 content | | | | | | | | | | | S2 icon | S2 content | | | | | == When what I want is: == | | | | S1 icon |S1 content | | | | | | | | | S2 icon |S2 content | | | | == So what I'm looking for is either a way to specify margin graphics without creating an artificial margin with tables, or to define the content of a cell in a top-level table from the template for an arbitrarily deep section. Maybe there's a simple xslt trick for doing this, but so far I haven't found it. Thanks for all the help so far! --Brad On Fri, Apr 9, 2010 at 6:04 AM, Arian armyofda12mnk...@gmail.com wrote: not sure if this is related but heres what Andreas told me before as i was wondering also why left margins/indents in my document seemed to be inherited if its helps out ... What this comes down to is that the margin-* properties --that exist solely for purposes of compatibility with CSS-- are mapped to the native XSL-FO properties *-indent. While the former are non-inherited, their native XSL-FO counterparts most certainly are. As pointed out on the Wiki, most implementations choose to ignore this, while FOP follows XSL-FO more strictly and forces you to use a configuration setting to trigger the CSS-like behavior. See also: http://xmlgraphics.apache.org/fop/0.95/configuration.html#general-elements (look for element 'break-indent-inheritance') That said, solving it by resetting start-indent to 0 on the fo:table would probably be the cleanest, from an XSL-FO point of view. Regards, Andreas -Arian - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- ~ Second Shift: An original, serialized audio adventure ~ http://www.secondshiftpodcast.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Alternatives to float graphics?
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 other ways of achieving a similar effect. The closest I've come is changing the section template to create a two-column table, with the icon on in col one and the content in col2, but this causes nested sections to get indented one column-width per level, which I don't want, because it creates nested tables. What I want is a single table wherein each section and sub-section is represented by a row with two columns: an icon (if applicable) in the left col, and the content in the right. But so far I'm having trouble figuring out how to do that in xslt. Before I hurt my brain too badly trying to figure out a way to implement this, I wanted to check here and see if anyone had other suggestions for how to get margin icons based on arbitrary section roles. Thanks, --Brad - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Inserting line-break symbols?
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 case a backslash. You could use any Unicode character you like, but the character has to be available to the XSL-FO processor at that point. Note that FOP does not support the hyphenate.verbatim feature at all. So, am I mis-understanding, or if I set wrap-option=wrap, hyphenate=true and hyphenation-character=\, should fop be able to do what I'm looking for or not? As it is, I've got everything but the hyphenation char showing up. Looking at fop's output I see Couldn't find hyphenation pattern none. After a bit of searching I figured out that I needed to set language=en_US in the root xslfo element and add the offo hyphenation jar to my classpath. I did that and while I no longer get the error about hyphenation patterns, the results I get makes no sense. Now, when a line that spills over, chunks of it get repeated over and over, filling the better part of the page with nonesense. So, basically: 1) Am I missing something simple that will add the appropriate hyphenation rules and ensure the fop follows them? 2) Even if I get that, will it ever work in conjunction with a hyphenation-character, or dig you mean abandon all hope when you noted that fop doesn't support hyphenate.verbatim? If the latter, why does fop bother (according to its docs, at least) implementing things like hyphenation-character? Thanks, --Brad - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Is it possible to prevent line breaks on '/'?
Adding keep-together.within-line=always to my filename template seems to have worked perfectly. Thanks! --Brad On Wed, Feb 3, 2010 at 6:27 AM, Vincent Hennebert vhenneb...@gmail.com wrote: Hi, Amick, Eric wrote: I haven't tried it, but I would expect fo:inline keep-together.within-line=always/mnt/install/fo:inline to do what you need. And if you need a more fine-grained solution, you can use the Word Joiner Unicode character (U+2060): /#x2060;mnt/install Especially in long URLs, you may want to allow line breaking after some slashes. HTH, Vincent Eric Amick Systems 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 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 line instead. How can that be done? --Brad - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- ~ Second Shift: An original, serialized audio adventure ~ http://www.secondshiftpodcast.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Is it possible to prevent line breaks on '/'?
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 line instead. How can that be done? --Brad - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Adding an image or character to denote line-wrap locations?
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 this, but it's a bit unreliable, since all it can do is count characters to figure out where lines should break. Does anyone know of a better way of dealing with this problem? Thanks! --Brad - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Problem with fo:block backgrounds on greyscale printer
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 fo:block font-weight=bold Note: /fo:block fo:block Yadda Yadda Yadda /fo:block /fo:block 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 has no background at all. Is there a more universal way I should be describing the background than #ee? Thanks! --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with fo:block backgrounds on greyscale printer
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 has no background at all. Is there a more universal way I should be describing the background than #ee? You could try something darker, like #DD or #CC. Then again, I've seen #E4E4E4 used as a company-standard somewhere... May have its reasons. OTOH, you can also use named colors, like 'lightgray' or 'lightgrey'. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- ~ Second Shift: An original, serialized audio adventure ~ http://www.secondshiftpodcast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Lines breaking on '/' and '-'
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 split after the '-' in it. It would be better for the line-breaks to be placed earlier so that the whole filename and the whole command name are kept to their own lines. I read earlier on this list that one of the source files can be modified and fop recompiled to solve similar problems in other languages, but is there a simpler way for English? Thanks, --Brad attachment: Screenshot.png- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lines breaking on '/' and '-'
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 letter characters. Eww.. that sounds like a hideous hack (not that you were implying otherwise). I think it would be a better solution to tweak the file that defines what chars are valid breakpoints and recompile. Then it'd at least work with any font. --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Korean words breaking in the middle
Hi Manuel, I'm trying to rebuild fop with the tweaked linebreak rules as described below, but I it fails, saying: junit: BUILD FAILED /home/brad/Work/fop/trunk/build.xml:947: NOTE: ** * One or more of the Junit tests had Failures or Errors or were skipped! * * Please check the output above for relevant messages. * *Or use the junit-reports target to generate HTML test reports.* ** The above output is hundreds of lines of info and warning messages, but no errors. I ran the junit-reports target and it shows 422 tests with 0 errors. I'm not sure what errors were skipped would entail. Any suggestions would be appreciated. I'm fairly certain I saw this the last time I attempted a build, so I don't think it's due 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 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 japanese lines, but trunk does. Brad, as stated before fop-trunk breaks Korean basically the same as Chinese, that is each consecutive pair of Korean characters are treated as a break opportunity. This is consistent with the default specified in the relevant Unicode standard. If you want to change this behaviour you need to change the line breaking pair table used by fop, this means building yourself a custom fop version. Here are some hints (not tested) how to do that. 1) Edit the file src/codegen/unicode/data/LineBreakPairTable.txt, which is basically a table, with a text editor. In the H2/H2, H2/H3, H3/H2, H3/H3 cells change the character _ (underscore) to % (percent). Note: Underscore indicates a direct break opportunity between characters of this class while percent indicates an indirect opportunity, that is break only if spaces intervene. 2) Now run the codegen-unicode ant target contained in the standard fop build.xml file. This should create a new LineBreakUtils.java file in the fop top level build directory. 3) Copy that file to src/java/org/apache/fop/text/linebreak 4) Rebuild fop Hope this helps Manuel --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- ~ Second Shift: An original, serialized audio adventure ~ http://www.secondshiftpodcast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Korean words breaking in the middle
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 problem. Any other suggestions would be appreciated. --Brad OP CL QU GL NS EX SY IS PR PO NU AL ID IN HY BA BB B2 ZW CM WJ H2 H3 JL JV JT OP ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ @ ^ ^ ^ ^ ^ ^ CL _ ^ % % ^ ^ ^ ^ % % % % _ _ % % _ _ ^ # ^ _ _ _ _ _ QU ^ ^ % % % ^ ^ ^ % % % % % % % % % % ^ # ^ % % % % % GL % ^ % % % ^ ^ ^ % % % % % % % % % % ^ # ^ % % % % % NS _ ^ % % % ^ ^ ^ _ _ _ _ _ _ % % _ _ ^ # ^ _ _ _ _ _ EX _ ^ % % % ^ ^ ^ _ _ _ _ _ _ % % _ _ ^ # ^ _ _ _ _ _ SY _ ^ % % % ^ ^ ^ _ _ % _ _ _ % % _ _ ^ # ^ _ _ _ _ _ IS _ ^ % % % ^ ^ ^ _ _ % % _ _ % % _ _ ^ # ^ _ _ _ _ _ PR % ^ % % % ^ ^ ^ _ _ % % % _ % % _ _ ^ # ^ % % % % % PO % ^ % % % ^ ^ ^ _ _ % % _ _ % % _ _ ^ # ^ _ _ _ _ _ NU % ^ % % % ^ ^ ^ % % % % _ % % % _ _ ^ # ^ _ _ _ _ _ AL % ^ % % % ^ ^ ^ _ _ % % _ % % % _ _ ^ # ^ _ _ _ _ _ ID _ ^ % % % ^ ^ ^ _ % _ _ _ % % % _ _ ^ # ^ _ _ _ _ _ IN _ ^ % % % ^ ^ ^ _ _ _ _ _ % % % _ _ ^ # ^ _ _ _ _ _ HY _ ^ % % % ^ ^ ^ _ _ % _ _ _ % % _ _ ^ # ^ _ _ _ _ _ BA _ ^ % % % ^ ^ ^ _ _ _ _ _ _ % % _ _ ^ # ^ _ _ _ _ _ BB % ^ % % % ^ ^ ^ % % % % % % % % % % ^ # ^ % % % % % B2 _ ^ % % % ^ ^ ^ _ _ _ _ _ _ % % _ ^ ^ # ^ _ _ _ _ _ ZW _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ^ _ _ _ _ _ _ _ CM _ ^ % % % ^ ^ ^ _ _ % % _ % % % _ _ ^ # ^ _ _ _ _ _ WJ % ^ % % % ^ ^ ^ % % % % % % % % % % ^ # ^ %
Re: Korean words breaking in the middle
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 japanese lines, but trunk does. --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Korean words breaking in the middle
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 wrap. The rectangle on the left shows the complete words as they should be rendered (unlike Japanese and Chinese, Korean uses space-delimited words like western languages). I've checked the source and there are no spaces within these words. Any ideas? Is a fix in the works for this? --Brad attachment: ko-wordbreak-crop.jpg- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fonts and bullet graphics?
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 had not known that. --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Alignment of chinese/english characters
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 problem is that when you mix in western characters and spaces, it seems to sometimes offset the line lengths. See the attached snippet for an example. I'm a bit confused by this, because line 1 has three western characters but sticks out farther than the others, even though line 2 has the two western characters and the same number of overall characters as line 1 and is the same width as the next line, which has only one western character and fewer overall characters. But more than what's causing the problem, I guess my question is: does anyone know a way to enforce line lengths in the way the my translator is asking for? I was hoping there might be a helpful fo:block property, but I'm not seeing it. Thanks a ton to anyone who can help, --Brad attachment: zh-CN-alignment_problem.jpg- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alignment of chinese/english characters
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 uses, or am I just going to have to try different monospace fonts and eyeball it? --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
fonts and bullet graphics?
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 the koran characters with #, the bullets are there again. So, from this I'm inferring that maybe the default bullet graphic is actually taken from the font? And this one doesn't have such a graphic? That seems like a long-shot, but I'm lacking any other plausible ideas, unless maybe it's a spacing issue and the font is just covering up the bullets? Looking at the document, I can't see any evidence of that, though. Any ideas/suggestions for how to deal with this would be greatly appreciated! --Brad -- ~ Second Shift: An original, serialized audio adventure ~ http://www.secondshiftpodcast.com
Re: fonts and bullet graphics?
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 [EMAIL PROTECTED] wrote: 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 the koran characters with #, the bullets are there again. So, from this I'm inferring that maybe the default bullet graphic is actually taken from the font? And this one doesn't have such a graphic? That seems like a long-shot, but I'm lacking any other plausible ideas, unless maybe it's a spacing issue and the font is just covering up the bullets? Looking at the document, I can't see any evidence of that, though. Any ideas/suggestions for how to deal with this would be greatly appreciated! --Brad -- ~ Second Shift: An original, serialized audio adventure ~ http://www.secondshiftpodcast.com -- ~ Second Shift: An original, serialized audio adventure ~ http://www.secondshiftpodcast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop and line-overruns using Japanese fonts
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop and line-overruns using Japanese fonts
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 commands, e-mail: [EMAIL PROTECTED]
Re: Fop and line-overruns using Japanese fonts
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 looking at the html reports generated by junit, no failures or errors were listed. From this I conclude that a test is being skipped. I do see the following in the output: hyphenation-present: [echo] Hyphenation Support NOT Present - Layout tests which require hyphenation are NOT being run! ...but should that really be a fatal error? Do I need to find an en_US.xml hyphenation file as described at http://xmlgraphics.apache.org/fop/0.20.5/hyphenation.html and put it in $build_dir/hyph for the build to work? Any help would be appreciated. --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fop and line-overruns using Japanese fonts
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 list found that this is a known issue and I read a suggestion to insert a zero-width space (\u200B, I assume) between each character as a fix. However, when I do this there is too little space between characters when I render, such that the glyphs all overlap one another. In some cases, they are also offset far to the left so that they off the left edge of the page instead of the right. I tried using a hair-space (\u200A) instead and had similar results. Does anyone have an alternate workaround? I'm using fop 0.93. --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
fop 0.93 RPM?
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, e-mail: [EMAIL PROTECTED]
Fop with Java 1.5?
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 system make a difference, then? How should I be approaching this? Sorry, I don't deal with java apps that much. Thanks, --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
fop doesn't like imagemagick'd pngs?
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
viewed in any image viewer. However, when included in a fop'd xslfo
file the version in the pdf looks... strange, like a bad photocopy.
I've attached an unchanged and a resized image for the adventurous.
Try including them both in a document and see if you get the same
result.
From everything I can tell, the resized image is a normal png, but if
I perform the same resize in eg Gimp, the resulting file looks a
little fuzzy in the pdf but is otherwise fine. So obviously
ImageMagick is doing something to the png that other viewers are ok
with, but not fop. On a probably related note, look how much bigger
the imagemagick'd file is than the original (27k vs 1b, in case this
list strips attachments)!
Does anyone have any insight into what's going on here? I'm on FC6
using fop-0.91beta-2 and ImageMagick-6.2.8.0 if that's relevant.
--Brad
test-orig.png
Description: PNG image
test-resized.png
Description: PNG image
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
