Re: RE: Does FOP support non-breaking hyphens?
May be post a fo snippet showing what you give to fop and then describe your expected and the actual output. Thank you for your answer! I am using FOP 0.95 (latest stable at the time of writing). I am trying the following fo snippet. fo:block This is the example with 2011 (as char) non breaking hyphen: This#8209;is#8209;a#8209;line#8209;with#8209;8209#8209;characters /fo:block fo:block This is the example with 2011 (as hex) non breaking hyphen: This#x2011;is#x2011;a#x2011;line#x2011;with#x2011;8209#x2011;characters /fo:block fo:block This is the example with 2011 (as number) non breaking hyphen: This#8209;is#8209;a#8209;line#8209;with#8209;8209#8209;characters /fo:block fo:block This is the example ZZ with an HTML shy hyphen: Bigandlongwordthatshouldbreakinalogicalplaceandnotgotothenextline /fo:block fo:block This is the example Z with non breaking space : Big#160;and#160;long#160;word#160;that#160;should#160;break#160;in#160;a#160;logical#160;place#160;and#160;not#160;go#160;to#160;the#160;next#160;line /fo:block Comments: - The hyphens in the first block are hex 2011 chars inserted directly into the FO file from the VIM editor - The hyphens in second block are entities with number 8209 - The hyphens in the third block are entities with hex 2011 - There are hyphens in 4th block with hex AD inserted directly by VIM - The non-breaking-space in the 5th block are entities with number 160 I run this snippet with FOP using fop -fo hyphens.xml hyphens.pdf Expected output First Block: This-is-a-line-with-8209-characters sentence appearing with hyphens but it should not break at any point. Second block: The same as first Third block: The same as first Fourth block: The sentence Bigandlong... with no visible hyphens. Only one visible hyphen when it breaks Fifth block: The sentence Big and long... with spaces but no break at all Actual output First block:The sentence appearing with # characters instead of hyphens Second block: Same as first Third block same as first Fourth block: As expected (so this works OK) Fifth block: As expeected (so this works OK) Thus the problem is that I get the # (sharp symbol) instead of a non-breaking-hyphen in the PDF output. I hope this is more clear. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Using keep-together.within-column and break-after results in missing text
Hello I am using FOP 0.95 (latest stable at the time of writing) and trying the following FO file. ?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master page-width=210mm page-height=297mm font-family=LiberationSerif master-name=pim-page fo:region-body margin-left=2.5cm margin-bottom=2cm margin-right=2.5cm margin-top=2cm/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=pim-page fo:flow flow-name=xsl-region-body fo:table border=1px fo:table-body fo:table-row keep-together.within-column=always fo:table-cell fo:block fo:block break-after=page Text on the first page. A page break should follow. /fo:block fo:blockText on the next page after the break/fo:block /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow /fo:page-sequence /fo:root I then convert it to PDF with fop -fo minimal.xml minimal.PDF Expected output Either (option 1): A PDF file with two pages with Text on the first .. shown in the first page and Text on the next... shown in the second (this means that break-after prevails) Or (option 2): A PDF file with only one page that contains both of the above sentences (the keep-together prevails) Actual Output A PDF file with two pages. Only the Text on the first.. appears on the document. The rest of Text on the next... is completely missing (not shown at all). What am I missing? Is this an issue or my mistake? Thank you. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: RE: Does FOP support non-breaking hyphens?
Thank you - yes it does make it more clear. The # is an indication that the font your are using has no matching glyph for the non breaking hyphen. From your initial post I incorrectly assumed that the problem was incorrect line breaking behaviour of the non breaking hyphen. Obviously that is not the case. For the time being the only solution I can offer is to find a font that contains a glyph for that code point. FOP is not doing anything wrong as such. Although an argument could be made that FOP should substitute the glyph for a normal hyphen when there is no glyph for the non breaking hyphen in the selected font. However, 'intelligent' glyph substitution is a more generic problem which I believe FOP has not tried to tackle so far. Manuel -Original Message- From: kkape...@freemail.gr [mailto:kkape...@freemail.gr] Sent: Thursday, 30 April 2009 4:23 PM To: fop-users@xmlgraphics.apache.org Subject: Re: RE: Does FOP support non-breaking hyphens? May be post a fo snippet showing what you give to fop and then describe your expected and the actual output. Thank you for your answer! I am using FOP 0.95 (latest stable at the time of writing). I am trying the following fo snippet. fo:block This is the example with 2011 (as char) non breaking hyphen: This#8209;is#8209;a#8209;line#8209;with#8209;8209#8209;characters /fo:block fo:block This is the example with 2011 (as hex) non breaking hyphen: This#x2011;is#x2011;a#x2011;line#x2011;with#x2011;8209#x2011;character s /fo:block fo:block This is the example with 2011 (as number) non breaking hyphen: This#8209;is#8209;a#8209;line#8209;with#8209;8209#8209;characters /fo:block fo:block This is the example ZZ with an HTML shy hyphen: Bigand-long-word-that-should-break-in-a-logical-place-and-not-go-to-the-next -line /fo:block fo:block This is the example Z with non breaking space : Big#160;and#160;long#160;word#160;that#160;should#160;break#160;in#1 60;a#160;logical#160;place#160;and#160;not#160;go#160;to#160;the#160 ;next#160;line /fo:block Comments: - The hyphens in the first block are hex 2011 chars inserted directly into the FO file from the VIM editor - The hyphens in second block are entities with number 8209 - The hyphens in the third block are entities with hex 2011 - There are hyphens in 4th block with hex AD inserted directly by VIM - The non-breaking-space in the 5th block are entities with number 160 I run this snippet with FOP using fop -fo hyphens.xml hyphens.pdf Expected output First Block: This-is-a-line-with-8209-characters sentence appearing with hyphens but it should not break at any point. Second block: The same as first Third block: The same as first Fourth block: The sentence Bigandlong... with no visible hyphens. Only one visible hyphen when it breaks Fifth block: The sentence Big and long... with spaces but no break at all Actual output First block:The sentence appearing with # characters instead of hyphens Second block: Same as first Third block same as first Fourth block: As expected (so this works OK) Fifth block: As expeected (so this works OK) Thus the problem is that I get the # (sharp symbol) instead of a non-breaking-hyphen in the PDF output. I hope this is more clear. - 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
Re: Using keep-together.within-column and break-after results in missing text
Hi, kkapelon freemail gr wrote: Hello I am using FOP 0.95 (latest stable at the time of writing) and trying the following FO file. snip/ I then convert it to PDF with fop -fo minimal.xml minimal.PDF Expected output Either (option 1): A PDF file with two pages with Text on the first .. shown in the first page and Text on the next... shown in the second (this means that break-after prevails) This is the expected output. Breaks must always be honoured, even if there are surrounding keeps. Or (option 2): A PDF file with only one page that contains both of the above sentences (the keep-together prevails) Actual Output A PDF file with two pages. Only the Text on the first.. appears on the document. The rest of Text on the next... is completely missing (not shown at all). What am I missing? Is this an issue or my mistake? This is a bug. Can you please file a bug report on Bugzilla, attaching your simple example? https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop Thanks, Vincent - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Incorrect display of accented characters in plain font
Fellow FOP users, I am looking for some help in an issue I am investigating for one of my clients that actually doesn't appear to have much to do with FOP at all. However, since there's a good chance that someone on this list knows more than I do about how fonts map to glyphs in PostScript, I figure this might be a good pool to ask. The issue is that a PDF generated from FOP with accented characters stored in the FO documented as Windows-1252 encoding, in either Helvetica or Times fonts, will display just fine when viewed in a PDF viewer, and they'll print just fine when printed from the PDF viewer. However, when that PDF is ran through a PostScript interpreter (Preview SDK from Liberty Systems), the accented characters are mangled. For example, é converts to D. What's strange is that this only happens if it's plain font -- not bold, italic, or bold-italic. Now I understand that plain, bold, italic, and bold-italic are 4 different fonts, and I've looked through the PostScript specification to see how the interpreter is supposed to map the font to the glyph, but I still can't figure out what's going on. And finally, when trying this same code execution here in house, in the US (the client is in France), I cannot reproduce the problem. Does anyone know if PostScript interpreters look anywhere on the PC itself (this is Windows) to find the font glyph information, or does anyone know why the decoding of characters would be different for one font than the other, even within the same font family? Thanks ahead of time for any clues you can offer. Sean Griffin | MSVC Architect | Cerner Corporation | 816.201.1599 | sgrif...@cerner.com | www.cerner.com http://www.cerner.com/ -- CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
RE: Incorrect display of accented characters in plain font
I need to clarify something I have below. It should be this: when that PDF is ran through a PostScript interpreter (Preview SDK from Liberty Systems) and sent to the printer, the accented characters are mangled on the printed output. From: Griffin,Sean [mailto:sgrif...@cerner.com] Sent: Thursday, April 30, 2009 9:04 AM To: fop-users@xmlgraphics.apache.org Subject: Incorrect display of accented characters in plain font Fellow FOP users, I am looking for some help in an issue I am investigating for one of my clients that actually doesn't appear to have much to do with FOP at all. However, since there's a good chance that someone on this list knows more than I do about how fonts map to glyphs in PostScript, I figure this might be a good pool to ask. The issue is that a PDF generated from FOP with accented characters stored in the FO documented as Windows-1252 encoding, in either Helvetica or Times fonts, will display just fine when viewed in a PDF viewer, and they'll print just fine when printed from the PDF viewer. However, when that PDF is ran through a PostScript interpreter (Preview SDK from Liberty Systems), the accented characters are mangled. For example, é converts to D. What's strange is that this only happens if it's plain font -- not bold, italic, or bold-italic. Now I understand that plain, bold, italic, and bold-italic are 4 different fonts, and I've looked through the PostScript specification to see how the interpreter is supposed to map the font to the glyph, but I still can't figure out what's going on. And finally, when trying this same code execution here in house, in the US (the client is in France), I cannot reproduce the problem. Does anyone know if PostScript interpreters look anywhere on the PC itself (this is Windows) to find the font glyph information, or does anyone know why the decoding of characters would be different for one font than the other, even within the same font family? Thanks ahead of time for any clues you can offer. Sean Griffin | MSVC Architect | Cerner Corporation | 816.201.1599 | sgrif...@cerner.com mailto:sgrif...@cerner.com | www.cerner.com http://www.cerner.com/ CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
