[xep-support] Re: String encoding issue

Thu Jul 19 12:31:39 PDT 2018

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:

<xep:text value="W" x="181103" y="428240" width="-270010"/>

<xep:text value="01I01:" x="-88907" y="428240" width="23090"/>

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 <kevin at renderx.com>
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 <kevin at renderx.com <mailto:kevin at renderx.com> > 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

 <mailto:kevin at renderx.com> kevin at renderx.com

 <mailto:sales at renderx.com> sales at renderx.com

 <http://www.renderx.com/> http://www.renderx.com 

From: Morley Tooke [mailto: <mailto:morley.tooke at gmail.com> morley.tooke at gmail.com] 
Sent: Thursday, July 19, 2018 9:52 AM
To: Kevin Brown < <mailto:kevin at renderx.com> kevin at renderx.com>; RenderX Community Support List < <mailto:xep-support at renderx.com> 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:

<fig id="fig_ddr_pvp_xdb" class="- topic/fig ">

   <title class="- topic/title ">Injection Well W01I01: Process Control</title>

...

fails to render the digits after the W and produces this output:

Figure: Injection Well W 

whereas this element:

 <fig id="fig_ddr_pvp_xdb" class="- topic/fig ">

   <title class="- topic/title ">Injection Well Y01I01: Process Control</title>

...

 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:

  <fo:block id="unique_11_Connect_42_fig_ddr_pvp_xdb"><fo:inline id="unique_11_Connect_42_image_cxc_yvw_j2b" margin-right="0.15in"><fo:external-graphic content-width="5.5in" src="url(images/fc_all_field_common_injection_well_W01_pcd.png)"/></fo:inline><fo:block 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</fo:block></fo:block>

  <fo:block id="unique_11_Connect_42_fig_ddr_pvp_xdb_d2e1293a1310"><fo:inline id="unique_11_Connect_42_image_cxc_yvw_j2b_d2e1298a1310" margin-right="0.15in"><fo:external-graphic content-width="5.5in" src="url(images/fc_all_field_common_injection_well_W01_pcd.png)"/></fo:inline><fo:block 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</fo:block></fo:block>

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 <kevin at renderx.com <mailto:kevin at renderx.com> > 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: <mailto:xep-support-bounces at renderx.com> xep-support-bounces at renderx.com] On Behalf Of Kevin Brown
Sent: Tuesday, July 17, 2018 11:37 AM
To: 'RenderX Community Support List' < <mailto:xep-support at renderx.com> 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> 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 < <mailto:xep-support at renderx.com> 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:

<title class="- topic/title ">Injection Well W01I01: Process Control</title>

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 <http://ww.renderx.com/terms-of-service.html> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20180719/e8e7d367/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 20156 bytes
Desc: not available
URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20180719/e8e7d367/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 38340 bytes
Desc: not available
URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20180719/e8e7d367/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 20288 bytes
Desc: not available
URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20180719/e8e7d367/attachment-0001.jpg>