Question
Apostrophe substitution when printing
Please bear with me. I'm an Arbortext novice, having recently joined a department with long-established procedures that I'm trying to get to grips with.
My colleagues have noticed a change in behaviour between Arbortext 5.4 and 6.0 in the printing of apostrophes.
In version 5.4, the straight, "typewriter" apostrophe (U+0027) output to both print and PDF as a "curly" apostrophe (U+2019). This suited us, since the print edition looked correct, but the HTML version retained the straight apostrophe, making searches more reliable.
(I should add that we publish partly in French, where there are a lot of apostrophes.)
Under version 6.0, straight apostrophes print as just that. To get a curly apostrophe we have to use the proper code - although as far as I can tell, whatever means we use to enter it, Arbortext represents it using the ’ entity. It looks fine on screen and in print, but messes up searches.
This could be considered "correct" behaviour, of course. It's just that we had been used to taking advantage of the earlier "incorrect" behaviour.
Has anyone else noticed this? Is there anything we can do to change it, or do we have to update our search routine?
(By the way, we have a case open with PTC on the issue, but they are taking some time to respond.)
David Crowe
My colleagues have noticed a change in behaviour between Arbortext 5.4 and 6.0 in the printing of apostrophes.
In version 5.4, the straight, "typewriter" apostrophe (U+0027) output to both print and PDF as a "curly" apostrophe (U+2019). This suited us, since the print edition looked correct, but the HTML version retained the straight apostrophe, making searches more reliable.
(I should add that we publish partly in French, where there are a lot of apostrophes.)
Under version 6.0, straight apostrophes print as just that. To get a curly apostrophe we have to use the proper code - although as far as I can tell, whatever means we use to enter it, Arbortext represents it using the ’ entity. It looks fine on screen and in print, but messes up searches.
This could be considered "correct" behaviour, of course. It's just that we had been used to taking advantage of the earlier "incorrect" behaviour.
Has anyone else noticed this? Is there anything we can do to change it, or do we have to update our search routine?
(By the way, we have a case open with PTC on the issue, but they are taking some time to respond.)
David Crowe

