cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Leave my apostrphes alone!

ClayHelberg
17-Peridot

Leave my apostrphes alone!

Hi all--

I'm having a strange issue with apostrophes (AKA single quotes). We have code samples where we want the straight quotes (Unicode 0x27) to remain straight, but they are now getting transmogrified into curly right single quotes (Unicode 0x2019). The strange part is that this only happens when producing PDF output in batch mode (running epic from the DOS command window with the -c option). If we run the exact same command from the command window within Arbortext, it preserves the straight quotes.

Anyone know why this would be happening, but only in batch mode? And more importantly, anyone know how to make it stop happening?

--Clay

Clay Helberg
Documentation Tools Programmer
The MathWorks

5 REPLIES 5

No specific info, Clay. Three random thoughts:

How are the quotes stored when saved to file? Are they Unicode characters or
character entities?

Are you using the content pipeline?

Does Editor still use two different parsers? One fast and one thorough? Try
removing the final PI which, I think (someone help me if I'm off in space),
tells Editor it has previously parsed the file. Not sure whether you'd do
that before composing interactively or by command line ... I guess both?

On Thu, Jul 17, 2008 at 3:04 PM, Clay Helberg <clay.helberg@mathworks.com>
wrote:

> Hi all--
>
>
>
> I'm having a strange issue with apostrophes (AKA single quotes). We have
> code samples where we want the straight quotes (Unicode 0x27) to remain
> straight, but they are now getting transmogrified into curly right single
> quotes (Unicode 0x2019). The strange part is that this only happens when
> producing PDF output in batch mode (running epic from the DOS command window
> with the -c option). If we run the exact same command from the command
> window within Arbortext, it preserves the straight quotes.
>
>
>
> Anyone know why this would be happening, but only in batch mode? And more
> importantly, anyone know how to make it stop happening?
>
>
>
> --Clay
>
>
>
> Clay Helberg
>
> Documentation Tools Programmer
>
> The MathWorks
>
>
>
>

Hi Paul--

Thanks for the strategic probing--here are some clarifications, which hopefully will jog someone's memory:

1) The quotes are saved as simple ASCII apostrophe characters--no fancy entities or numeric character references, just press the button next to the Enter key.

When generating PDF interactively (load document and compose to PDF), the resulting PDF contains the correct characters, i.e. the regular apostrophe characters just like in the source document--I verified this by copying the text and pasting into a hex editor to see the character values. By the same method, I can see that when I compose from the command line, the apostrophe characters are replaced with ’ characters.

2) I'm not sure about the pipeline. It does seem like a potential candidate, but I'm not sure what conditions control use of the pipeline. I know that I get good output interactively regardless of whether I turn on profiling or not. Is there a way to know for sure, on any particular publish, whether the pipeline is active?

3) I'm not sure about the parsers, but my recollection is that one is primarily for SGML docs and the other is for XML docs. Plus, I doubt it has anything to do with processing instructions in the doc--my tests are based on the same document, with no changes between tests, so the same PI's would be there under all conditions. (The doc is in source control, so Arbortext can't change it even if it wants to.)

My hunch is that this is something in the guts of Arbortext that tries to optimize processing when in terminal (batch) mode, but also has the side effect of changing straight single quotes to curly quotes.

If it matters, we're using Arbortext Editor 5.3 M030 with Print Composer running locally.

--Clay

>
> 2) I'm not sure about the pipeline. It does seem like a potential
> candidate, but I'm not sure what conditions control use of the pipeline. I
> know that I get good output interactively regardless of whether I turn on
> profiling or not. Is there a way to know for sure, on any particular
> publish, whether the pipeline is active?


I'm not sure how to *detect* it, but I know that profiling and DLM trigger
the pipeline. I'm thinking there is a third, common trigger, but it's
escaping me now. One of the PDFs (or Help Center) might have more on what
functionality triggers it.



> 3) I'm not sure about the parsers, but my recollection is that one is
> primarily for SGML docs and the other is for XML docs. Plus, I doubt it has
> anything to do with processing instructions in the doc--my tests are based
> on the same document, with no changes between tests, so the same PI's would
> be there under all conditions. (The doc is in source control, so Arbortext
> can't change it even if it wants to.)


It was/is a reach, but I was wondering if one parser is used always in batch
while in interactive, a choice may be made depending on various things, one
of which is whether or not Arbortext had read it before. I was thinking if
you could force the parser to flip from one to the other in one of the
modes, you might see different behavior. Admittedly this idea was also
paired with recollections of problems we had with some character entities,
charent.cf, and the pipeline prematurely resolving character to font and
losing that before the end of the pipeline.

Are the apostrophes rendering in the PDF in the same typeface as each other
and the rest of the text?

--
Paul Nagai

Hi Clay,
Just a shot in the dark here. Is it possible that your two different
modes are using two different printer drivers to produce PostScript for
creating the PDF? It could be an issue with fonts on printers.

Print drivers sound like a good possibility. I know we've had issues in
the past with the print driver that we have set as default under the
service account we use for our E3 server. Set to the wrong driver, our
PDFs come out with embedded font issues that hose certain glyphs (fl and
fi in particular).

I don't know if there's a diff when using the pipeline, particularly
using profiling, since we don't currently use profiling, but worth
checking into...

-Jason
Announcements