From morley.tooke at gmail.com Tue Jul 17 11:32:12 2018 From: morley.tooke at gmail.com (Morley Tooke) Date: Tue, 17 Jul 2018 14:32:12 -0400 Subject: [xep-support] String encoding issue Message-ID: Hello, One of my writers has run into an issue where a string of numbers in a fig is being rendered out of his topic. I've seen this once before with a very similar string.This is his code: Injection Well W01I01: Process Control His output looks something like this: *Injection Well W* There is nothing special in the PDF customization code. This is the rest of his email to me: *The basic gist is that I have a well that is labelled W010I01. And when I enter that label in body text, it renders fine in the PDF. However, when I enter it in a fig title tag, the W will render, but the rest of the text is left blank. EG:* *I have tried a few variations in the title text to see what happens. Adding a space between W and 0 works fine: * *As does replacing the first 0 with a capital O: * *But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen are interpreting that W01xxx as something other than plain text, and removing it from the document altogether. * Thanks in advance, Morley -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at renderx.com Tue Jul 17 11:37:12 2018 From: kevin at renderx.com (Kevin Brown) Date: Tue, 17 Jul 2018 11:37:12 -0700 Subject: [xep-support] Re: String encoding issue In-Reply-To: References: Message-ID: <083c01d41dfd$2d966770$88c33650$@renderx.com> It is completely unclear how this relates to RenderX but one guess would be that you are using different fonts in each of the two representations. One font contains those glyphs, the other does not. Check what fonts are used in each of two cases. Kevin Brown From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf Of Morley Tooke Sent: Tuesday, July 17, 2018 11:32 AM To: RenderX Community Support List Subject: [xep-support] String encoding issue Hello, One of my writers has run into an issue where a string of numbers in a fig is being rendered out of his topic. I've seen this once before with a very similar string.This is his code: Injection Well W01I01: Process Control His output looks something like this: Injection Well W There is nothing special in the PDF customization code. This is the rest of his email to me: The basic gist is that I have a well that is labelled W010I01. And when I enter that label in body text, it renders fine in the PDF. However, when I enter it in a fig title tag, the W will render, but the rest of the text is left blank. EG: I have tried a few variations in the title text to see what happens. Adding a space between W and 0 works fine: As does replacing the first 0 with a capital O: But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen are interpreting that W01xxx as something other than plain text, and removing it from the document altogether. Thanks in advance, Morley -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at renderx.com Tue Jul 17 11:46:43 2018 From: kevin at renderx.com (Kevin Brown) Date: Tue, 17 Jul 2018 11:46:43 -0700 Subject: [xep-support] Re: String encoding issue In-Reply-To: <083c01d41dfd$2d966770$88c33650$@renderx.com> References: <083c01d41dfd$2d966770$88c33650$@renderx.com> Message-ID: <084f01d41dfe$825452d0$86fcf870$@renderx.com> Another debug test would be to run the document to FO (do not delete the final FO that is being sent). Examine that. 1) Are the characters there or not? If they are not ? it is something in the DITA/XSL chain and has nothing to do with the PDF generation. 2) If they are ? then post the two snippets of the FO so we can examine what fonts are used and what character selection strategy Kevin Brown RenderX From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf Of Kevin Brown Sent: Tuesday, July 17, 2018 11:37 AM To: 'RenderX Community Support List' Subject: [xep-support] Re: String encoding issue It is completely unclear how this relates to RenderX but one guess would be that you are using different fonts in each of the two representations. One font contains those glyphs, the other does not. Check what fonts are used in each of two cases. Kevin Brown From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf Of Morley Tooke Sent: Tuesday, July 17, 2018 11:32 AM To: RenderX Community Support List > Subject: [xep-support] String encoding issue Hello, One of my writers has run into an issue where a string of numbers in a fig is being rendered out of his topic. I've seen this once before with a very similar string.This is his code: Injection Well W01I01: Process Control His output looks something like this: Injection Well W There is nothing special in the PDF customization code. This is the rest of his email to me: The basic gist is that I have a well that is labelled W010I01. And when I enter that label in body text, it renders fine in the PDF. However, when I enter it in a fig title tag, the W will render, but the rest of the text is left blank. EG: I have tried a few variations in the title text to see what happens. Adding a space between W and 0 works fine: As does replacing the first 0 with a capital O: But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen are interpreting that W01xxx as something other than plain text, and removing it from the document altogether. Thanks in advance, Morley -------------- next part -------------- An HTML attachment was scrubbed... URL: From morley.tooke at gmail.com Tue Jul 17 11:52:55 2018 From: morley.tooke at gmail.com (Morley Tooke) Date: Tue, 17 Jul 2018 14:52:55 -0400 Subject: [xep-support] Re: String encoding issue In-Reply-To: <084f01d41dfe$825452d0$86fcf870$@renderx.com> References: <083c01d41dfd$2d966770$88c33650$@renderx.com> <084f01d41dfe$825452d0$86fcf870$@renderx.com> Message-ID: Thanks, I'll take a look. This is being run as part of an EasyDITA integration, so it's a little bit hard to debug, but I have a similar setup locally that I can test on. RE: font/glyph issue - I don't think that is the problem. Those are regular numeric characters in a fig title element. We have thousands of pages of content with hundreds of similar equipment tag elements. For whatever reason (this has happened twice now in three years) certain combinations of those characters in the element tag are causing the text to disappear. It's almost like an internal code or value that the rendering engine is picking up. On Tue, Jul 17, 2018 at 2:46 PM Kevin Brown wrote: > Another debug test would be to run the document to FO (do not delete the > final FO that is being sent). > > Examine that. > > 1) Are the characters there or not? If they are not ? it is > something in the DITA/XSL chain and has nothing to do with the PDF > generation. > > 2) If they are ? then post the two snippets of the FO so we can > examine what fonts are used and what character selection strategy > > > > Kevin Brown > > RenderX > > > > *From:* Xep-support [mailto:xep-support-bounces at renderx.com] *On Behalf > Of *Kevin Brown > *Sent:* Tuesday, July 17, 2018 11:37 AM > *To:* 'RenderX Community Support List' > *Subject:* [xep-support] Re: String encoding issue > > > > It is completely unclear how this relates to RenderX but one guess would > be that you are using different fonts in each of the two representations. > > One font contains those glyphs, the other does not. > > Check what fonts are used in each of two cases. > > > > Kevin Brown > > > > > > *From:* Xep-support [mailto:xep-support-bounces at renderx.com > ] *On Behalf Of *Morley Tooke > *Sent:* Tuesday, July 17, 2018 11:32 AM > *To:* RenderX Community Support List > *Subject:* [xep-support] String encoding issue > > > > Hello, > > > > One of my writers has run into an issue where a string of numbers in a > fig is being rendered out of his topic. I've seen this once before with a > very similar string.This is his code: > > > > Injection Well W01I01: Process > Control > > > > His output looks something like this: > > > > *Injection Well W* > > > > There is nothing special in the PDF customization code. > > > > This is the rest of his email to me: > > > > *The basic gist is that I have a well that is labelled W010I01. And when I > enter that label in body text, it renders fine in the PDF. However, when I > enter it in a fig title tag, the W will render, but the rest of the text is > left blank. EG:* > > > > *I have tried a few variations in the title text to see what happens. > Adding a space between W and 0 works fine:* > > > > *As does replacing the first 0 with a capital O:* > > > > *But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen are > interpreting that W01xxx as something other than plain text, and removing > it from the document altogether. * > > > > Thanks in advance, > > > > Morley > > > > > _______________________________________________ > (*) To unsubscribe, please visit > http://lists.renderx.com/mailman/options/xep-support > (*) By using the Service, you expressly agree to these Terms of Service > http://w > ww.renderx.com/terms-of-service.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From morley.tooke at gmail.com Thu Jul 19 09:51:32 2018 From: morley.tooke at gmail.com (Morley Tooke) Date: Thu, 19 Jul 2018 12:51:32 -0400 Subject: [xep-support] Re: String encoding issue In-Reply-To: <084f01d41dfe$825452d0$86fcf870$@renderx.com> References: <083c01d41dfd$2d966770$88c33650$@renderx.com> <084f01d41dfe$825452d0$86fcf870$@renderx.com> Message-ID: Hi Kevin, I've done some more digging on this. To refresh you, this element: Injection Well W01I01: Process Control ... fails to render the digits after the W and produces this output: *Figure: Injection Well W* whereas this element: Injection Well Y01I01: Process Control ... produces this output: *Figure: Injection Well Y01I01: Process Control* I can change that string to anything else and it works fine, but this string seems to get picked up by some other process. This is what my FO looks like: Figure 7: Injection Well W01I01: Process Control Figure 8: Injection Well Y01I01: Process Control Other things: 1. The html output works as expected. 2. The stock dita pdf2 output has the same error, so it doesn't seem to be my custommization. 3. I'm using Version 4.24.395 I'm at a loss. I've tweaked my customization and found nothing (attrs and xslt) .Can you please create a fig.title element with that string in it and see what happens? Thanks On Tue, Jul 17, 2018 at 2:46 PM Kevin Brown wrote: > Another debug test would be to run the document to FO (do not delete the > final FO that is being sent). > > Examine that. > > 1) Are the characters there or not? If they are not ? it is > something in the DITA/XSL chain and has nothing to do with the PDF > generation. > > 2) If they are ? then post the two snippets of the FO so we can > examine what fonts are used and what character selection strategy > > > > Kevin Brown > > RenderX > > > > *From:* Xep-support [mailto:xep-support-bounces at renderx.com] *On Behalf > Of *Kevin Brown > *Sent:* Tuesday, July 17, 2018 11:37 AM > *To:* 'RenderX Community Support List' > *Subject:* [xep-support] Re: String encoding issue > > > > It is completely unclear how this relates to RenderX but one guess would > be that you are using different fonts in each of the two representations. > > One font contains those glyphs, the other does not. > > Check what fonts are used in each of two cases. > > > > Kevin Brown > > > > > > *From:* Xep-support [mailto:xep-support-bounces at renderx.com > ] *On Behalf Of *Morley Tooke > *Sent:* Tuesday, July 17, 2018 11:32 AM > *To:* RenderX Community Support List > *Subject:* [xep-support] String encoding issue > > > > Hello, > > > > One of my writers has run into an issue where a string of numbers in a > fig is being rendered out of his topic. I've seen this once before with a > very similar string.This is his code: > > > > Injection Well W01I01: Process > Control > > > > His output looks something like this: > > > > *Injection Well W* > > > > There is nothing special in the PDF customization code. > > > > This is the rest of his email to me: > > > > *The basic gist is that I have a well that is labelled W010I01. And when I > enter that label in body text, it renders fine in the PDF. However, when I > enter it in a fig title tag, the W will render, but the rest of the text is > left blank. EG:* > > > > *I have tried a few variations in the title text to see what happens. > Adding a space between W and 0 works fine:* > > > > *As does replacing the first 0 with a capital O:* > > > > *But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen are > interpreting that W01xxx as something other than plain text, and removing > it from the document altogether. * > > > > Thanks in advance, > > > > Morley > > > > > _______________________________________________ > (*) To unsubscribe, please visit > http://lists.renderx.com/mailman/options/xep-support > (*) By using the Service, you expressly agree to these Terms of Service > http://w > ww.renderx.com/terms-of-service.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at renderx.com Thu Jul 19 10:13:08 2018 From: kevin at renderx.com (Kevin Brown) Date: Thu, 19 Jul 2018 10:13:08 -0700 Subject: [xep-support] Re: String encoding issue In-Reply-To: References: <083c01d41dfd$2d966770$88c33650$@renderx.com> <084f01d41dfe$825452d0$86fcf870$@renderx.com> Message-ID: <0d1a01d41f83$c4070c00$4c152400$@renderx.com> I do not quite understand the statement: 2. The stock dita pdf2 output has the same error, so it doesn't seem to be my custommization. Do you mean using FOP and you get the same result as using RenderX? If yes, then it is most certainly elsewhere. Is that is the exact FO that goes to the formatter? Or is there something else in between? I can certainly format that (and did attached) but to fully replicate this, you should send me: 1) Agenda bold font as it would be used if available on the system and I assume it is on yours 2) The referenced image Also look through the whole FO and see if you have a character-selection-strategy set somewhere above these in the hierarchy Kevin Brown (650) 327-1000 Direct (650) 328-8008 Fax (925) 395-1772 Mobile skype:kbrown01 kevin at renderx.com sales at renderx.com http://www.renderx.com From: Morley Tooke [mailto:morley.tooke at gmail.com] Sent: Thursday, July 19, 2018 9:52 AM To: Kevin Brown ; RenderX Community Support List Subject: Re: [xep-support] Re: String encoding issue Hi Kevin, I've done some more digging on this. To refresh you, this element: Injection Well W01I01: Process Control ... fails to render the digits after the W and produces this output: Figure: Injection Well W whereas this element: Injection Well Y01I01: Process Control ... produces this output: Figure: Injection Well Y01I01: Process Control I can change that string to anything else and it works fine, but this string seems to get picked up by some other process. This is what my FO looks like: Figure 7: Injection Well W01I01: Process Control Figure 8: Injection Well Y01I01: Process Control Other things: 1. The html output works as expected. 2. The stock dita pdf2 output has the same error, so it doesn't seem to be my custommization. 3. I'm using Version 4.24.395 I'm at a loss. I've tweaked my customization and found nothing (attrs and xslt) .Can you please create a fig.title element with that string in it and see what happens? Thanks On Tue, Jul 17, 2018 at 2:46 PM Kevin Brown > wrote: Another debug test would be to run the document to FO (do not delete the final FO that is being sent). Examine that. 1) Are the characters there or not? If they are not ? it is something in the DITA/XSL chain and has nothing to do with the PDF generation. 2) If they are ? then post the two snippets of the FO so we can examine what fonts are used and what character selection strategy Kevin Brown RenderX From: Xep-support [mailto:xep-support-bounces at renderx.com ] On Behalf Of Kevin Brown Sent: Tuesday, July 17, 2018 11:37 AM To: 'RenderX Community Support List' > Subject: [xep-support] Re: String encoding issue It is completely unclear how this relates to RenderX but one guess would be that you are using different fonts in each of the two representations. One font contains those glyphs, the other does not. Check what fonts are used in each of two cases. Kevin Brown From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf Of Morley Tooke Sent: Tuesday, July 17, 2018 11:32 AM To: RenderX Community Support List > Subject: [xep-support] String encoding issue Hello, One of my writers has run into an issue where a string of numbers in a fig is being rendered out of his topic. I've seen this once before with a very similar string.This is his code: Injection Well W01I01: Process Control His output looks something like this: Injection Well W There is nothing special in the PDF customization code. This is the rest of his email to me: The basic gist is that I have a well that is labelled W010I01. And when I enter that label in body text, it renders fine in the PDF. However, when I enter it in a fig title tag, the W will render, but the rest of the text is left blank. EG: I have tried a few variations in the title text to see what happens. Adding a space between W and 0 works fine: As does replacing the first 0 with a capital O: But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen are interpreting that W01xxx as something other than plain text, and removing it from the document altogether. Thanks in advance, Morley _______________________________________________ (*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support (*) By using the Service, you expressly agree to these Terms of Service http://w ww.renderx.com/terms-of-service.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testing.pdf Type: application/pdf Size: 5470 bytes Desc: not available URL: From kevin at renderx.com Thu Jul 19 12:31:39 2018 From: kevin at renderx.com (Kevin Brown) Date: Thu, 19 Jul 2018 12:31:39 -0700 Subject: [xep-support] Re: String encoding issue In-Reply-To: References: <083c01d41dfd$2d966770$88c33650$@renderx.com> <084f01d41dfe$825452d0$86fcf870$@renderx.com> <0d1a01d41f83$c4070c00$4c152400$@renderx.com> Message-ID: <0db901d41f97$1e2cc400$5a864c00$@renderx.com> So you are not crazy. There is something wrong/broken and it is inside the Agenda-Bold font. I changed your FO to use that font for that string. If I examine the XEP Intermediate format, I see this: Something about the W is not working for that font, it has something wrong in the font file with the kern information. It?s width is calculated as -270010 XEP Units. The remainder of the string after the W you see starts way off the page at x of -88907 units. To test this I changed XEP in the xep.xml to not KERN and it works: Now as a further test to prove it is likely the font, I installed your Agenda-Bold font in Windows and then fired up Word. I pasted in your line of text and selected that font for it. I then changed the character style to Kern (as Word does not Kern by default) and BANG! Look at my screen shot: That font is broken. Period. Kevin Brown RenderX From: Morley Tooke [mailto:morley.tooke at gmail.com] Sent: Thursday, July 19, 2018 10:56 AM To: Kevin Brown Subject: Re: [xep-support] Re: String encoding issue I do not quite understand the statement: 2. The stock dita pdf2 output has the same error, so it doesn't seem to be my custommization. I'm running the out-of-the box DITA PDF2 transform, which means I'm not running my customization (trying to narrow the problem). This transform still uses XEP, not fop. When I run the transform with fop, the string shows up as expected. This is the exact FO that goes to the formatter. Thanks for looking at this. Morley On Thu, Jul 19, 2018 at 1:13 PM Kevin Brown > wrote: I do not quite understand the statement: 2. The stock dita pdf2 output has the same error, so it doesn't seem to be my custommization. Do you mean using FOP and you get the same result as using RenderX? If yes, then it is most certainly elsewhere. Is that is the exact FO that goes to the formatter? Or is there something else in between? I can certainly format that (and did attached) but to fully replicate this, you should send me: 1) Agenda bold font as it would be used if available on the system and I assume it is on yours 2) The referenced image Also look through the whole FO and see if you have a character-selection-strategy set somewhere above these in the hierarchy Kevin Brown (650) 327-1000 Direct (650) 328-8008 Fax (925) 395-1772 Mobile skype:kbrown01 kevin at renderx.com sales at renderx.com http://www.renderx.com From: Morley Tooke [mailto: morley.tooke at gmail.com] Sent: Thursday, July 19, 2018 9:52 AM To: Kevin Brown < kevin at renderx.com>; RenderX Community Support List < xep-support at renderx.com> Subject: Re: [xep-support] Re: String encoding issue Hi Kevin, I've done some more digging on this. To refresh you, this element: Injection Well W01I01: Process Control ... fails to render the digits after the W and produces this output: Figure: Injection Well W whereas this element: Injection Well Y01I01: Process Control ... produces this output: Figure: Injection Well Y01I01: Process Control I can change that string to anything else and it works fine, but this string seems to get picked up by some other process. This is what my FO looks like: Figure 7: Injection Well W01I01: Process Control Figure 8: Injection Well Y01I01: Process Control Other things: 1. The html output works as expected. 2. The stock dita pdf2 output has the same error, so it doesn't seem to be my custommization. 3. I'm using Version 4.24.395 I'm at a loss. I've tweaked my customization and found nothing (attrs and xslt) .Can you please create a fig.title element with that string in it and see what happens? Thanks On Tue, Jul 17, 2018 at 2:46 PM Kevin Brown > wrote: Another debug test would be to run the document to FO (do not delete the final FO that is being sent). Examine that. 1) Are the characters there or not? If they are not ? it is something in the DITA/XSL chain and has nothing to do with the PDF generation. 2) If they are ? then post the two snippets of the FO so we can examine what fonts are used and what character selection strategy Kevin Brown RenderX From: Xep-support [mailto: xep-support-bounces at renderx.com] On Behalf Of Kevin Brown Sent: Tuesday, July 17, 2018 11:37 AM To: 'RenderX Community Support List' < xep-support at renderx.com> Subject: [xep-support] Re: String encoding issue It is completely unclear how this relates to RenderX but one guess would be that you are using different fonts in each of the two representations. One font contains those glyphs, the other does not. Check what fonts are used in each of two cases. Kevin Brown From: Xep-support [ mailto:xep-support-bounces at renderx.com] On Behalf Of Morley Tooke Sent: Tuesday, July 17, 2018 11:32 AM To: RenderX Community Support List < xep-support at renderx.com> Subject: [xep-support] String encoding issue Hello, One of my writers has run into an issue where a string of numbers in a fig is being rendered out of his topic. I've seen this once before with a very similar string.This is his code: Injection Well W01I01: Process Control His output looks something like this: Injection Well W There is nothing special in the PDF customization code. This is the rest of his email to me: The basic gist is that I have a well that is labelled W010I01. And when I enter that label in body text, it renders fine in the PDF. However, when I enter it in a fig title tag, the W will render, but the rest of the text is left blank. EG: I have tried a few variations in the title text to see what happens. Adding a space between W and 0 works fine: As does replacing the first 0 with a capital O: But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen are interpreting that W01xxx as something other than plain text, and removing it from the document altogether. Thanks in advance, Morley _______________________________________________ (*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support (*) By using the Service, you expressly agree to these Terms of Service http://w ww.renderx.com/terms-of-service.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 20156 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 38340 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 20288 bytes Desc: not available URL: From dave.pawson at gmail.com Thu Jul 19 23:29:31 2018 From: dave.pawson at gmail.com (Dave Pawson) Date: Fri, 20 Jul 2018 07:29:31 +0100 Subject: [xep-support] Re: String encoding issue In-Reply-To: References: <083c01d41dfd$2d966770$88c33650$@renderx.com> <084f01d41dfe$825452d0$86fcf870$@renderx.com> Message-ID: Wondering if it is an encoding issue? utf-8 all the way through? XML, XSLT and XSL-FO? HTH On 19 July 2018 at 17:51, Morley Tooke wrote: > Hi Kevin, > > I've done some more digging on this. > > To refresh you, this element: > > > Injection Well W01I01: Process > Control > ... > fails to render the digits after the W and produces this output: > > Figure: Injection Well W > > whereas this element: > > > Injection Well Y01I01: Process > Control > ... > > produces this output: > > Figure: Injection Well Y01I01: Process Control > > I can change that string to anything else and it works fine, but this string > seems to get picked up by some other process. > > This is what my FO looks like: > > id="unique_11_Connect_42_image_cxc_yvw_j2b" > margin-right="0.15in"> src="url(images/fc_all_field_common_injection_well_W01_pcd.png)"/> font-size="10pt" font-weight="bold" > keep-with-previous.within-column="always" > keep-with-previous.within-page="always" space-after="10pt" > space-before="0pt" line-height-shift-adjustment="disregard-shifts" > font-family="agenda,helvetica,Symbol">Figure 7: Injection Well W01I01: > Process Control > > id="unique_11_Connect_42_fig_ddr_pvp_xdb_d2e1293a1310"> id="unique_11_Connect_42_image_cxc_yvw_j2b_d2e1298a1310" > margin-right="0.15in"> src="url(images/fc_all_field_common_injection_well_W01_pcd.png)"/> font-size="10pt" font-weight="bold" > keep-with-previous.within-column="always" > keep-with-previous.within-page="always" space-after="10pt" > space-before="0pt" line-height-shift-adjustment="disregard-shifts" > font-family="agenda,helvetica,Symbol">Figure 8: Injection Well Y01I01: > Process Control > > Other things: > > 1. The html output works as expected. > 2. The stock dita pdf2 output has the same error, so it doesn't seem to be > my custommization. > 3. I'm using Version 4.24.395 > > I'm at a loss. I've tweaked my customization and found nothing (attrs and > xslt) .Can you please create a fig.title element with that string in it and > see what happens? > > Thanks > > > > On Tue, Jul 17, 2018 at 2:46 PM Kevin Brown wrote: >> >> Another debug test would be to run the document to FO (do not delete the >> final FO that is being sent). >> >> Examine that. >> >> 1) Are the characters there or not? If they are not ? it is something >> in the DITA/XSL chain and has nothing to do with the PDF generation. >> >> 2) If they are ? then post the two snippets of the FO so we can >> examine what fonts are used and what character selection strategy >> >> >> >> Kevin Brown >> >> RenderX >> >> >> >> From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf Of >> Kevin Brown >> Sent: Tuesday, July 17, 2018 11:37 AM >> To: 'RenderX Community Support List' >> Subject: [xep-support] Re: String encoding issue >> >> >> >> It is completely unclear how this relates to RenderX but one guess would >> be that you are using different fonts in each of the two representations. >> >> One font contains those glyphs, the other does not. >> >> Check what fonts are used in each of two cases. >> >> >> >> Kevin Brown >> >> >> >> >> >> From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf Of >> Morley Tooke >> Sent: Tuesday, July 17, 2018 11:32 AM >> To: RenderX Community Support List >> Subject: [xep-support] String encoding issue >> >> >> >> Hello, >> >> >> >> One of my writers has run into an issue where a string of numbers in a fig >> is being rendered out of his topic. I've seen this once before with a very >> similar string.This is his code: >> >> >> >> Injection Well W01I01: Process >> Control >> >> >> >> His output looks something like this: >> >> >> >> Injection Well W >> >> >> >> There is nothing special in the PDF customization code. >> >> >> >> This is the rest of his email to me: >> >> >> >> The basic gist is that I have a well that is labelled W010I01. And when I >> enter that label in body text, it renders fine in the PDF. However, when I >> enter it in a fig title tag, the W will render, but the rest of the text is >> left blank. EG: >> >> >> >> I have tried a few variations in the title text to see what happens. >> Adding a space between W and 0 works fine: >> >> >> >> As does replacing the first 0 with a capital O: >> >> >> >> But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen are >> interpreting that W01xxx as something other than plain text, and removing it >> from the document altogether. >> >> >> >> Thanks in advance, >> >> >> >> Morley >> >> >> >> >> >> _______________________________________________ >> (*) To unsubscribe, please visit >> http://lists.renderx.com/mailman/options/xep-support >> (*) By using the Service, you expressly agree to these Terms of Service >> http://w >> ww.renderx.com/terms-of-service.html > > > _______________________________________________ > (*) To unsubscribe, please visit > http://lists.renderx.com/mailman/options/xep-support > (*) By using the Service, you expressly agree to these Terms of Service > http://w > ww.renderx.com/terms-of-service.html -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. From kevin at renderx.com Fri Jul 20 10:45:51 2018 From: kevin at renderx.com (Kevin Brown) Date: Fri, 20 Jul 2018 10:45:51 -0700 Subject: [xep-support] Re: String encoding issue In-Reply-To: References: <083c01d41dfd$2d966770$88c33650$@renderx.com> <084f01d41dfe$825452d0$86fcf870$@renderx.com> Message-ID: <100b01d42051$80ac43c0$8204cb40$@renderx.com> Maybe this was not posted on xep-support as several files went back and forth between Morley and myself. To close this out, the issue was the actual font file. It has a broken Kern table in it. Since Kerning is on by default in RenderX, the Kern information in this font for the 'W' has a huge negative offset in it and sent the remaining content off the page. We first formatted the document using Helvetica and all was there. We set back to the Agenda-Bold font and saw the content missing. We validated by formatting to XEP intermediate and examining where text was being placed (it was there, not removed). The text was being placed at an x location of -88907 units, way off the left side of the page. Then we formatted with Kern turned off and the text was there as expected in the correct location because it was not Kerned. Then we used the Agenda-Bold font in Word and set the Kerning on and showed that it was also broken (nothing to do with XEP). The font itself is bad. Kevin Brown RenderX -----Original Message----- From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf Of Dave Pawson Sent: Thursday, July 19, 2018 11:30 PM To: RenderX Community Support List Subject: [xep-support] Re: String encoding issue Wondering if it is an encoding issue? utf-8 all the way through? XML, XSLT and XSL-FO? HTH On 19 July 2018 at 17:51, Morley Tooke wrote: > Hi Kevin, > > I've done some more digging on this. > > To refresh you, this element: > > > Injection Well W01I01: Process > Control ... > fails to render the digits after the W and produces this output: > > Figure: Injection Well W > > whereas this element: > > > Injection Well Y01I01: Process > Control ... > > produces this output: > > Figure: Injection Well Y01I01: Process Control > > I can change that string to anything else and it works fine, but this > string seems to get picked up by some other process. > > This is what my FO looks like: > > id="unique_11_Connect_42_image_cxc_yvw_j2b" > margin-right="0.15in"> src="url(images/fc_all_field_common_injection_well_W01_pcd.png)"/> :inline> font-size="10pt" font-weight="bold" > keep-with-previous.within-column="always" > keep-with-previous.within-page="always" space-after="10pt" > space-before="0pt" line-height-shift-adjustment="disregard-shifts" > font-family="agenda,helvetica,Symbol">Figure 7: Injection Well W01I01: > Process Control > > id="unique_11_Connect_42_fig_ddr_pvp_xdb_d2e1293a1310"> id="unique_11_Connect_42_image_cxc_yvw_j2b_d2e1298a1310" > margin-right="0.15in"> src="url(images/fc_all_field_common_injection_well_W01_pcd.png)"/> :inline> font-size="10pt" font-weight="bold" > keep-with-previous.within-column="always" > keep-with-previous.within-page="always" space-after="10pt" > space-before="0pt" line-height-shift-adjustment="disregard-shifts" > font-family="agenda,helvetica,Symbol">Figure 8: Injection Well Y01I01: > Process Control > > Other things: > > 1. The html output works as expected. > 2. The stock dita pdf2 output has the same error, so it doesn't seem > to be my custommization. > 3. I'm using Version 4.24.395 > > I'm at a loss. I've tweaked my customization and found nothing (attrs > and > xslt) .Can you please create a fig.title element with that string in > it and see what happens? > > Thanks > > > > On Tue, Jul 17, 2018 at 2:46 PM Kevin Brown wrote: >> >> Another debug test would be to run the document to FO (do not delete >> the final FO that is being sent). >> >> Examine that. >> >> 1) Are the characters there or not? If they are not ? it is something >> in the DITA/XSL chain and has nothing to do with the PDF generation. >> >> 2) If they are ? then post the two snippets of the FO so we can >> examine what fonts are used and what character selection strategy >> >> >> >> Kevin Brown >> >> RenderX >> >> >> >> From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf >> Of Kevin Brown >> Sent: Tuesday, July 17, 2018 11:37 AM >> To: 'RenderX Community Support List' >> Subject: [xep-support] Re: String encoding issue >> >> >> >> It is completely unclear how this relates to RenderX but one guess >> would be that you are using different fonts in each of the two representations. >> >> One font contains those glyphs, the other does not. >> >> Check what fonts are used in each of two cases. >> >> >> >> Kevin Brown >> >> >> >> >> >> From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf >> Of Morley Tooke >> Sent: Tuesday, July 17, 2018 11:32 AM >> To: RenderX Community Support List >> Subject: [xep-support] String encoding issue >> >> >> >> Hello, >> >> >> >> One of my writers has run into an issue where a string of numbers in >> a fig is being rendered out of his topic. I've seen this once before >> with a very similar string.This is his code: >> >> >> >> Injection Well W01I01: Process >> Control >> >> >> >> His output looks something like this: >> >> >> >> Injection Well W >> >> >> >> There is nothing special in the PDF customization code. >> >> >> >> This is the rest of his email to me: >> >> >> >> The basic gist is that I have a well that is labelled W010I01. And >> when I enter that label in body text, it renders fine in the PDF. >> However, when I enter it in a fig title tag, the W will render, but >> the rest of the text is left blank. EG: >> >> >> >> I have tried a few variations in the title text to see what happens. >> Adding a space between W and 0 works fine: >> >> >> >> As does replacing the first 0 with a capital O: >> >> >> >> But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen >> are interpreting that W01xxx as something other than plain text, and >> removing it from the document altogether. >> >> >> >> Thanks in advance, >> >> >> >> Morley >> >> >> >> >> >> _______________________________________________ >> (*) To unsubscribe, please visit >> http://lists.renderx.com/mailman/options/xep-support >> (*) By using the Service, you expressly agree to these Terms of >> Service http://w ww.renderx.com/terms-of-service.html > > > _______________________________________________ > (*) To unsubscribe, please visit > http://lists.renderx.com/mailman/options/xep-support > (*) By using the Service, you expressly agree to these Terms of Service > http://w > ww.renderx.com/terms-of-service.html -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. _______________________________________________ (*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support (*) By using the Service, you expressly agree to these Terms of Service http://w ww.renderx.com/terms-of-service.html From dave.pawson at gmail.com Fri Jul 20 11:25:12 2018 From: dave.pawson at gmail.com (Dave Pawson) Date: Fri, 20 Jul 2018 19:25:12 +0100 Subject: [xep-support] Re: String encoding issue In-Reply-To: <100b01d42051$80ac43c0$8204cb40$@renderx.com> References: <083c01d41dfd$2d966770$88c33650$@renderx.com> <084f01d41dfe$825452d0$86fcf870$@renderx.com> <100b01d42051$80ac43c0$8204cb40$@renderx.com> Message-ID: Wow. A rarity I hop Kevin! Not straight forward to find either. regards On 20 July 2018 at 18:45, Kevin Brown wrote: > Maybe this was not posted on xep-support as several files went back and forth between Morley and myself. > To close this out, the issue was the actual font file. > > It has a broken Kern table in it. > Since Kerning is on by default in RenderX, the Kern information in this font for the 'W' has a huge negative offset in it and sent the remaining content off the page. > > We first formatted the document using Helvetica and all was there. > We set back to the Agenda-Bold font and saw the content missing. > We validated by formatting to XEP intermediate and examining where text was being placed (it was there, not removed). > The text was being placed at an x location of -88907 units, way off the left side of the page. > Then we formatted with Kern turned off and the text was there as expected in the correct location because it was not Kerned. > Then we used the Agenda-Bold font in Word and set the Kerning on and showed that it was also broken (nothing to do with XEP). > > The font itself is bad. > > Kevin Brown > RenderX > > -----Original Message----- > From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf Of Dave Pawson > Sent: Thursday, July 19, 2018 11:30 PM > To: RenderX Community Support List > Subject: [xep-support] Re: String encoding issue > > Wondering if it is an encoding issue? > utf-8 all the way through? XML, XSLT and XSL-FO? > > HTH > > On 19 July 2018 at 17:51, Morley Tooke wrote: >> Hi Kevin, >> >> I've done some more digging on this. >> >> To refresh you, this element: >> >> >> Injection Well W01I01: Process >> Control ... >> fails to render the digits after the W and produces this output: >> >> Figure: Injection Well W >> >> whereas this element: >> >> >> Injection Well Y01I01: Process >> Control ... >> >> produces this output: >> >> Figure: Injection Well Y01I01: Process Control >> >> I can change that string to anything else and it works fine, but this >> string seems to get picked up by some other process. >> >> This is what my FO looks like: >> >> > id="unique_11_Connect_42_image_cxc_yvw_j2b" >> margin-right="0.15in">> src="url(images/fc_all_field_common_injection_well_W01_pcd.png)"/>> :inline>> font-size="10pt" font-weight="bold" >> keep-with-previous.within-column="always" >> keep-with-previous.within-page="always" space-after="10pt" >> space-before="0pt" line-height-shift-adjustment="disregard-shifts" >> font-family="agenda,helvetica,Symbol">Figure 7: Injection Well W01I01: >> Process Control >> >> > id="unique_11_Connect_42_fig_ddr_pvp_xdb_d2e1293a1310">> id="unique_11_Connect_42_image_cxc_yvw_j2b_d2e1298a1310" >> margin-right="0.15in">> src="url(images/fc_all_field_common_injection_well_W01_pcd.png)"/>> :inline>> font-size="10pt" font-weight="bold" >> keep-with-previous.within-column="always" >> keep-with-previous.within-page="always" space-after="10pt" >> space-before="0pt" line-height-shift-adjustment="disregard-shifts" >> font-family="agenda,helvetica,Symbol">Figure 8: Injection Well Y01I01: >> Process Control >> >> Other things: >> >> 1. The html output works as expected. >> 2. The stock dita pdf2 output has the same error, so it doesn't seem >> to be my custommization. >> 3. I'm using Version 4.24.395 >> >> I'm at a loss. I've tweaked my customization and found nothing (attrs >> and >> xslt) .Can you please create a fig.title element with that string in >> it and see what happens? >> >> Thanks >> >> >> >> On Tue, Jul 17, 2018 at 2:46 PM Kevin Brown wrote: >>> >>> Another debug test would be to run the document to FO (do not delete >>> the final FO that is being sent). >>> >>> Examine that. >>> >>> 1) Are the characters there or not? If they are not ? it is something >>> in the DITA/XSL chain and has nothing to do with the PDF generation. >>> >>> 2) If they are ? then post the two snippets of the FO so we can >>> examine what fonts are used and what character selection strategy >>> >>> >>> >>> Kevin Brown >>> >>> RenderX >>> >>> >>> >>> From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf >>> Of Kevin Brown >>> Sent: Tuesday, July 17, 2018 11:37 AM >>> To: 'RenderX Community Support List' >>> Subject: [xep-support] Re: String encoding issue >>> >>> >>> >>> It is completely unclear how this relates to RenderX but one guess >>> would be that you are using different fonts in each of the two representations. >>> >>> One font contains those glyphs, the other does not. >>> >>> Check what fonts are used in each of two cases. >>> >>> >>> >>> Kevin Brown >>> >>> >>> >>> >>> >>> From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf >>> Of Morley Tooke >>> Sent: Tuesday, July 17, 2018 11:32 AM >>> To: RenderX Community Support List >>> Subject: [xep-support] String encoding issue >>> >>> >>> >>> Hello, >>> >>> >>> >>> One of my writers has run into an issue where a string of numbers in >>> a fig is being rendered out of his topic. I've seen this once before >>> with a very similar string.This is his code: >>> >>> >>> >>> Injection Well W01I01: Process >>> Control >>> >>> >>> >>> His output looks something like this: >>> >>> >>> >>> Injection Well W >>> >>> >>> >>> There is nothing special in the PDF customization code. >>> >>> >>> >>> This is the rest of his email to me: >>> >>> >>> >>> The basic gist is that I have a well that is labelled W010I01. And >>> when I enter that label in body text, it renders fine in the PDF. >>> However, when I enter it in a fig title tag, the W will render, but >>> the rest of the text is left blank. EG: >>> >>> >>> >>> I have tried a few variations in the title text to see what happens. >>> Adding a space between W and 0 works fine: >>> >>> >>> >>> As does replacing the first 0 with a capital O: >>> >>> >>> >>> But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen >>> are interpreting that W01xxx as something other than plain text, and >>> removing it from the document altogether. >>> >>> >>> >>> Thanks in advance, >>> >>> >>> >>> Morley >>> >>> >>> >>> >>> >>> _______________________________________________ >>> (*) To unsubscribe, please visit >>> http://lists.renderx.com/mailman/options/xep-support >>> (*) By using the Service, you expressly agree to these Terms of >>> Service http://w ww.renderx.com/terms-of-service.html >> >> >> _______________________________________________ >> (*) To unsubscribe, please visit >> http://lists.renderx.com/mailman/options/xep-support >> (*) By using the Service, you expressly agree to these Terms of Service >> http://w >> ww.renderx.com/terms-of-service.html > > > > -- > Dave Pawson > XSLT XSL-FO FAQ. > Docbook FAQ. > > _______________________________________________ > (*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support > (*) By using the Service, you expressly agree to these Terms of Service http://w > ww.renderx.com/terms-of-service.html > > _______________________________________________ > (*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support > (*) By using the Service, you expressly agree to these Terms of Service http://w > ww.renderx.com/terms-of-service.html -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. From kevin at renderx.com Fri Jul 20 11:46:09 2018 From: kevin at renderx.com (Kevin Brown) Date: Fri, 20 Jul 2018 11:46:09 -0700 Subject: [xep-support] Re: String encoding issue In-Reply-To: References: <083c01d41dfd$2d966770$88c33650$@renderx.com> <084f01d41dfe$825452d0$86fcf870$@renderx.com> <100b01d42051$80ac43c0$8204cb40$@renderx.com> Message-ID: <104901d42059$edc1db70$c9459250$@renderx.com> I would love it to be a rarity ... but alas ... there are a million lamely created fonts in the world ... or they are rip offs of commercial ones done with some convertor that breaks them. When I saw that the content was in the FO but not in the PDF, I had about 99.99% certainty it was in the font. There are no hidden key phrases that RenderX would fail to render! Kevin -----Original Message----- From: Dave Pawson [mailto:dave.pawson at gmail.com] Sent: Friday, July 20, 2018 11:25 AM To: Kevin Brown ; RenderX Community Support List Subject: Re: [xep-support] Re: String encoding issue Wow. A rarity I hop Kevin! Not straight forward to find either. regards On 20 July 2018 at 18:45, Kevin Brown wrote: > Maybe this was not posted on xep-support as several files went back and forth between Morley and myself. > To close this out, the issue was the actual font file. > > It has a broken Kern table in it. > Since Kerning is on by default in RenderX, the Kern information in this font for the 'W' has a huge negative offset in it and sent the remaining content off the page. > > We first formatted the document using Helvetica and all was there. > We set back to the Agenda-Bold font and saw the content missing. > We validated by formatting to XEP intermediate and examining where text was being placed (it was there, not removed). > The text was being placed at an x location of -88907 units, way off the left side of the page. > Then we formatted with Kern turned off and the text was there as expected in the correct location because it was not Kerned. > Then we used the Agenda-Bold font in Word and set the Kerning on and showed that it was also broken (nothing to do with XEP). > > The font itself is bad. > > Kevin Brown > RenderX > > -----Original Message----- > From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf > Of Dave Pawson > Sent: Thursday, July 19, 2018 11:30 PM > To: RenderX Community Support List > Subject: [xep-support] Re: String encoding issue > > Wondering if it is an encoding issue? > utf-8 all the way through? XML, XSLT and XSL-FO? > > HTH > > On 19 July 2018 at 17:51, Morley Tooke wrote: >> Hi Kevin, >> >> I've done some more digging on this. >> >> To refresh you, this element: >> >> >> Injection Well W01I01: Process >> Control ... >> fails to render the digits after the W and produces this output: >> >> Figure: Injection Well W >> >> whereas this element: >> >> >> Injection Well Y01I01: Process >> Control ... >> >> produces this output: >> >> Figure: Injection Well Y01I01: Process Control >> >> I can change that string to anything else and it works fine, but this >> string seems to get picked up by some other process. >> >> This is what my FO looks like: >> >> > id="unique_11_Connect_42_image_cxc_yvw_j2b" >> margin-right="0.15in">> src="url(images/fc_all_field_common_injection_well_W01_pcd.png)"/>> o >> :inline>> font-size="10pt" font-weight="bold" >> keep-with-previous.within-column="always" >> keep-with-previous.within-page="always" space-after="10pt" >> space-before="0pt" line-height-shift-adjustment="disregard-shifts" >> font-family="agenda,helvetica,Symbol">Figure 7: Injection Well W01I01: >> Process Control >> >> > id="unique_11_Connect_42_fig_ddr_pvp_xdb_d2e1293a1310">> id="unique_11_Connect_42_image_cxc_yvw_j2b_d2e1298a1310" >> margin-right="0.15in">> src="url(images/fc_all_field_common_injection_well_W01_pcd.png)"/>> o >> :inline>> font-size="10pt" font-weight="bold" >> keep-with-previous.within-column="always" >> keep-with-previous.within-page="always" space-after="10pt" >> space-before="0pt" line-height-shift-adjustment="disregard-shifts" >> font-family="agenda,helvetica,Symbol">Figure 8: Injection Well Y01I01: >> Process Control >> >> Other things: >> >> 1. The html output works as expected. >> 2. The stock dita pdf2 output has the same error, so it doesn't seem >> to be my custommization. >> 3. I'm using Version 4.24.395 >> >> I'm at a loss. I've tweaked my customization and found nothing (attrs >> and >> xslt) .Can you please create a fig.title element with that string in >> it and see what happens? >> >> Thanks >> >> >> >> On Tue, Jul 17, 2018 at 2:46 PM Kevin Brown wrote: >>> >>> Another debug test would be to run the document to FO (do not delete >>> the final FO that is being sent). >>> >>> Examine that. >>> >>> 1) Are the characters there or not? If they are not ? it is something >>> in the DITA/XSL chain and has nothing to do with the PDF generation. >>> >>> 2) If they are ? then post the two snippets of the FO so we can >>> examine what fonts are used and what character selection strategy >>> >>> >>> >>> Kevin Brown >>> >>> RenderX >>> >>> >>> >>> From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf >>> Of Kevin Brown >>> Sent: Tuesday, July 17, 2018 11:37 AM >>> To: 'RenderX Community Support List' >>> Subject: [xep-support] Re: String encoding issue >>> >>> >>> >>> It is completely unclear how this relates to RenderX but one guess >>> would be that you are using different fonts in each of the two representations. >>> >>> One font contains those glyphs, the other does not. >>> >>> Check what fonts are used in each of two cases. >>> >>> >>> >>> Kevin Brown >>> >>> >>> >>> >>> >>> From: Xep-support [mailto:xep-support-bounces at renderx.com] On Behalf >>> Of Morley Tooke >>> Sent: Tuesday, July 17, 2018 11:32 AM >>> To: RenderX Community Support List >>> Subject: [xep-support] String encoding issue >>> >>> >>> >>> Hello, >>> >>> >>> >>> One of my writers has run into an issue where a string of numbers in >>> a fig is being rendered out of his topic. I've seen this once before >>> with a very similar string.This is his code: >>> >>> >>> >>> Injection Well W01I01: Process >>> Control >>> >>> >>> >>> His output looks something like this: >>> >>> >>> >>> Injection Well W >>> >>> >>> >>> There is nothing special in the PDF customization code. >>> >>> >>> >>> This is the rest of his email to me: >>> >>> >>> >>> The basic gist is that I have a well that is labelled W010I01. And >>> when I enter that label in body text, it renders fine in the PDF. >>> However, when I enter it in a fig title tag, the W will render, but >>> the rest of the text is left blank. EG: >>> >>> >>> >>> I have tried a few variations in the title text to see what happens. >>> Adding a space between W and 0 works fine: >>> >>> >>> >>> As does replacing the first 0 with a capital O: >>> >>> >>> >>> But W01xxx is a no-go. So, far as I can gather, EasyDITA or Oxygen >>> are interpreting that W01xxx as something other than plain text, and >>> removing it from the document altogether. >>> >>> >>> >>> Thanks in advance, >>> >>> >>> >>> Morley >>> >>> >>> >>> >>> >>> _______________________________________________ >>> (*) To unsubscribe, please visit >>> http://lists.renderx.com/mailman/options/xep-support >>> (*) By using the Service, you expressly agree to these Terms of >>> Service http://w ww.renderx.com/terms-of-service.html >> >> >> _______________________________________________ >> (*) To unsubscribe, please visit >> http://lists.renderx.com/mailman/options/xep-support >> (*) By using the Service, you expressly agree to these Terms of >> Service http://w ww.renderx.com/terms-of-service.html > > > > -- > Dave Pawson > XSLT XSL-FO FAQ. > Docbook FAQ. > > _______________________________________________ > (*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support > (*) By using the Service, you expressly agree to these Terms of Service http://w > ww.renderx.com/terms-of-service.html > > _______________________________________________ > (*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support > (*) By using the Service, you expressly agree to these Terms of Service http://w > ww.renderx.com/terms-of-service.html -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ.