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

Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X

Chinese fonts & Arbortext Styler

ptc-2451440
1-Newbie

Chinese fonts & Arbortext Styler

Hi All,

I'm having difficulty configuring the proper font sets for Traditional and Simplified Chinese in a FOSI-based Styler stylesheet.

We've had success with both Japanese and Korean, but seem to be stuck with Chinese. In both Chinese variations, the formatter kicks out errors indicating the system is searching for our characters in the Japanese font set. From what I understand of how the system moves through font substitutions of the tfontsub configuration file, it seems that the system does not recognize any font that I set for chs or cht, rolls to the first font in the windowsonly fonts (Japanese), and then finally tries the default font, Arial.

I'm suspicious that the publishing pipeline doesn't recognize that we're dealing with Chinese content. Is there any way to check this?

I appreciate any insight or troubleshooting tips.

Thank you,

Anne

2 REPLIES 2
pnagai
4-Participant
(To:ptc-2451440)

Hi Anne,

A long time ago we had trouble with single characters we were controling through the font configuration files. What we learned at that point (admitedly, this was many versions ago, possibly even 4.x) was that the XML submitted to Publishing Engine was parsed multiple times as the job moved through the content pipeline. If your composition request is very simple, it may avoid the pipeline and the multiple parsings. (For example, DLM and profiling will individually trigger a pass through the pipeline.)

The problem we had at the time was that the config file specifying a character entity be resolved to a specific character in our font was being applied on the first parse in the pipeline. Subsequent parsings ignored the config file. At the time, Arbortext felt this was correct behavior. We were able to use a workaround (creating elements with attributes that would survive the trip through the pipeline and be resolved by the stylesheet, for example, <arial_ms type="euro">). I never agreed this was correct, but didn't pursue it. It was my belief (still is) that the font config should only be applied to the final parsing prior to the stylesheet.

ANYHOW, if this relates to your problem, one way to diagnose it would be to create a dead-simple composition request. Disable DLM. Do not profile. Research the pipeline if necessary to figure out if anything else you are doing will trigger a pass through the pipeline and disable or omit anything that would do so.

If your composition request succeeds, you will have very useful information for your next step (or for support if you've got a case open by then).

Finally you should submit the question to the Adepters mailing list where lots and lots of Arbortext users, admins, and developers hang out 24/7/366 (it is a leap year, you know!). I have zero experience with Arbortext and CJK languages (or any other). Many on that mailing list do. They might be able to recognize a quicker, simpler path to happiness if this is something they've encountered before.

Information on joining that list (as well as pointers to lots of other Arbortext resources) can be found here:

http://blog.single-sourcing.com/top-arbortext-resources

Good luck!

Thanks, Paul! Very interesting. I'm with you--it makes since that the font config would be applied as a final step. Thanks for your other thoughts; no profiling with this content, and I'm not familiar with DLM, but will research. I did also post on Adepters. Kind regards, Anne

Top Tags