problem of specific fonts with print composer

[unknown1]

I use Arbortext Editor + Print Composer + FOSI. I configured my FOSI
to use specific fonts like "Trebuchet ms" or "BankGothic
Md BT". The fonts are displayed well in Arbortext
Editor, but at the time of the impression, they are replaced by a
font by default (Arial).
Do you have a solution to resolve my problem?
Kind Regards.

[lhales]

David,

Do the FOSI fonts print if you do a screen print (Print Editor View)? If
they are changed then, does the printer support the fonts you have
selected? Try it in Macro$carf Word (or some other better word
processor).

Do the fonts appear in Print Preview or if you have the capability, in a
PDF file using the generic PDF printer driver?

I would like to think that if the font is installed on your system, it
would print as long as the printer supports the font.

I guess this is one of the 'joys' (sic) of not having to deal with a lot
of formal output (like Andy and Ed have to do). I don't get to 'dig into'
the print process a whole lot. 😞

Lynn

[ebenton]

If you are using Print Composer, you are probably using the default
printer driver on your PC to create PostScript files, which are then
Distilled to PDF via Acrobat Distiller. Check your default printer to
see if those fonts are supported by it. Usually, if you use Acrobat
Distiller as your default printer, things come out fairly well. There
are also settings in Acrobat Distiller and the Acrobat Distiller printer
for font locations and whether to embed certain fonts or not.

[unknown1]

The fonts print if I do a screen print (Print Editor View).
The fonts don’t appear in Print Preview and in a PDF file.

David GOPOIS
Responsable Informatique / Computer Manager
Tél.: (+33) 02 35 12 33 66
Fax: (+33) 02 35 12 33 67

Groupe INGELIANCE
INTERFACE
230, route de Préaux
76160 Roncherolles sur le vivier - FRANCE

-----Message d'origine-----
De : Lynn Hales
Envoyé : mercredi 26 juillet 2006 14:07
À : adepters@arbortext.com
Objet : Re: problem of specific fonts with print composer

David,

Do the FOSI fonts print if you do a screen print (Print Editor View)? If
they are changed then, does the printer support the fonts you have
selected? Try it in Macro$carf Word (or some other better word
processor).

Do the fonts appear in Print Preview or if you have the capability, in a
PDF file using the generic PDF printer driver?

I would like to think that if the font is installed on your system, it
would print as long as the printer supports the font.

I guess this is one of the 'joys' (sic) of not having to deal with a lot
of formal output (like Andy and Ed have to do). I don't get to 'dig into'
the print process a whole lot. 😞

Lynn

[lhales]

Ouch, now that makes things a bit more difficult. I was hoping the Editor
view would not print properly either. 😞 But we have narrowed things
down to something in the actual publication process. Just what it is, I
am at a loss to determine.

What you may want to try is to dig into the print output file (Ed or Andy,
help me with the extension name here) to see where the fonts may be being
changed, if in fact they are.

One way to quickly find this might be to add a test output string (FOSI
<usetext>) that changes the FONT on some weird string (like five Z's in a
row). Or even before doing that, do a <usetext> with a common font (like
Courier) and see if the change takes place in the output.

Lynn

[GregoryMackenzi]

Hi,

As a rule of thumb if it displays it should print, providing you aren't
using a screen fosi and a print fosi. Try a print preview and see what
happens.

You'll likely need to do a liitle reading on the whole subject as there
could be a number of things causing your font to default to Aial. You
might want to do a little digging into the help files for information on
how fonts are handled. Recently I had to conduct an expedition into
fixing our own fosi to use some different fonts. Along the way I found
that Epic has some defaults that may need to be looked at and are set
via a file in the epic installtion folder. In our case I even found some
font substitutions which are handled via an environment variable
setting. One of my fonts was being substituted with Arial and I had to
remove the substitutions.

I had a problem getting a particular font to download into a PDF. Most
of my problems needed to be solved by editing a localized version of our
FOSI and looking at the Document Default, setting the base font there,
also in the page layout (some fonts were specified there) and going into
the base styles and a few of the e-i-cs to set the font attributes of
anything that needed specific attention. That's our FOSI though, yours
is likely quite different. Fortunately, Epic recognized the windows
fonts installed on my machine when I wanted to specify the fonts in the
FOSI. In my case many font references were Arial and needed to be
changed to the font we wanted to use.

Good Luck!

Greg
🙂

>>> david.gopois@ingeliance.com 07/26/06 09:05AM >>>
I use Arbortext Editor + Print Composer + FOSI. I configured my FOSI
to use specific fonts like "Trebuchet ms" or "BankGothic
Md BT". The fonts are displayed well in Arbortext
Editor, but at the time of the impression, they are replaced by a
font by default (Arial).
Do you have a solution to resolve my problem?
Kind Regards. >> To unsubscribe from the list, send an email to
listmanager@maillist.arbortext.com with the following in the body:
unsubscribe adepters - For additional information on the adepters list
(how to subscribe or unsubscribe etc), send an email to:
listmanager@maillist.arbortext.com with the following in the body:
info Adepters - You may also go to forums.arbortext.com, enter the
Adepters folder and change your subscription options and preferences.>>

[DavidS.Taylor]

David:

What version of Epic/Arbortext are you using?

Font management in Epic 4.3.1 requires individual font configuration files for editing and for preview/printing. These configuration files should be located in the 'custom' directory tree and need some environment variables set to tell Epic what to look for.

Also check to make sure the font you want isn't being substituted with Arial by your printer. Many Postsript printers default to substitute fonts when the named font is not available on the printer. This setting can be changed to force downloading of a font at print time if the printer doesn't already have the font installed.

Ed may call tables 'the spawn of Satan' but for me, over the last few years, that label could have been equally applied as well to fonts!

Good luck!

David

David S. Taylor

Project Manager, Structured Information
Institute for Research in Construction
National Research Council Canada
Bldg. M-23A, Room 239
1200 Montreal Road, Ottawa, ON K1A 0R6

[ptc-1787870]

I had some similar font substitution problems, but this using PE 5.2. Tech
support was made aware of the particular issue and an SPR generated.

However, as you say you're using Print Composer, I'm guessing you're on a
different version. If fonts are installed on client and server, you should
be good.

Regards,
Jason




"Taylor, David S." <david.s.taylor@nrc-cnrc.gc.ca>
07/26/2006 10:01 AM
Please respond to
<adepters@arbortext.com>


To
<adepters@arbortext.com>
cc

Subject
RE: RE : problem of specific fonts with print composer






David:

What version of Epic/Arbortext are you using?

Font management in Epic 4.3.1 requires individual font configuration files
for editing and for preview/printing. These configuration files should be
located in the 'custom' directory tree and need some environment variables
set to tell Epic what to look for.

Also check to make sure the font you want isn't being substituted with
Arial by your printer. Many Postsript printers default to substitute
fonts when the named font is not available on the printer. This setting
can be changed to force downloading of a font at print time if the printer
doesn't already have the font installed.

Ed may call tables 'the spawn of Satan' but for me, over the last few
years, that label could have been equally applied as well to fonts!

Good luck!

David

David S. Taylor

Project Manager, Structured Information
Institute for Research in Construction
National Research Council Canada
Bldg. M-23A, Room 239
1200 Montreal Road, Ottawa, ON K1A 0R6

[lhales]

In the markup world, I think Ed is right, "Tables are the spawn of Satan."
Shoot even in the non markup world, a table is a royal PITA (Pain In The
A**). Once you have succumbed to getting your tables ready for
publication, then I would tend to agree with David T. Making printers
work (aren't we supposed to be becoming a PAPERLESS society?) properly
moves right up there.

David T., you have to admit that working with printers under Windoze has
improved. Try getting a printer to work in the MS-DOS world. AHHHHHH..

Ed, here's a couple for you.

1. I had one the folks using our DTD call me the other day and ask a
'table' question. Make sure you are sitting down in a chair with arms. I
don't want you falling down or out of the chair and hurting your self. The
question. "How do I expand the width of a SINGLE table cell?" Not span
multiple columns, but make one cell in a column wider than the others. He
said he'd done it before, but forgot how. Strange smelly cigarettes I
guess. 🙂

2. My boss has started looking at the Macro$carf Word support for XML
(WordML). He bought a book from Amazon and has been 'playing'. He said
that if you think tables are bad, I should look at how Macro$carf's WordML
handles LISTS.

Lynn

[DavidS.Taylor]

Would that lead to fonts/printers being "spawn of Satan's spawn" (grand-spawn?)...

MS-DOS was conceived in the days of 9-pin dot matrix printers - wasn't printing so much easier back then? 😉 Windoze has indeed come a long way from its 3.1 days, I think we mostly blame the applications and the printer drivers now when we have problems; there seems to be a never-ending stream of updates for both to download and apply.

Unix has to be the worst OS in which to try and print anything of consequence. Has the original printing environment ever been updated? Printer manufacturers don't even want to talk about setting up their printers on a Unix system!

As Lynn says, "aren't we supposed to be becoming a PAPERLESS society?" I think I first heard this phrase in 1971! Looking around my office at the moment, I would say we have a long way to go.

One last thought on Lynn's comment about Word and XML. Left to its own devices, Word creates the worst XML files you're ever likely to see. They are only of any use in Word, completely destroying the purpose for using XML in the first place (is "Macro$carf" trying to hijack XML?). However...

I've had some good results using XML in Word 2003, as long as the files are ALWAYS saved as "DATA ONLY" each and every time they are saved. When editing an XML document with a schema, the "data only" file includes only the tags and attributes described in the schema. I was able to move a number of XML files from Epic 4.3.1 into Word 2003, send them out for translation into French, and bring them back into Epic without any significant problem. The only caveat was that the translators were told to not touch any tags, simply overtype the English text with the French.

I'm hoping to expand on this initial step in the fall, after getting away for some vacation time.

I hope David G. has made some progress with his font issue. David???

Cheers,

David T.

[jdreystadt]

Lynn,

Regarding your first item, try the following:

Using AXDocBook (and this should work in other doctypes as well
depending on the table model but I just tried this in AXDocBook and it
worked for me) insert an informal table. Put the cursor in the last cell
of the table. Use the Forward arrow to move out of the table one click
only. Insert a table again. You should wind up with an informaltable
with two tgroup tags underneath the informaltable. Column widths can be
different between the different tgroups.

No strange smelly cigarettes were harmed in doing this.

John Dreystadt
Software Development Director
Arbortext - PTC
734-327-6079
-

[lhales]

John,

Thanks for the idea. I'll try it and if it isn't too difficult, I may
even pass it on to the writer who asked. He needs the KISS principle most
of the time. But multiple <tgroups> would work. Might look like
something one would want to avoid stepping in, but it would work.

Lynn

[lhales]

See my comments interspersed below.

[naglists]

I don't know if you're still on the hunt on this one, but if so:

If you are connecting characters to fonts via charent.cf AND you are
doing anything that triggers the content pipeline you may be losing
that association. Something to do with the multiple parsings (and thus
premature assocation of font) as the XML moves from pipe to pipe to
pipe. We use elements like <zapf_char type="check"> and resolve the
correct font/character in the stylesheet (last pipe) to get around
this issue.

Profiling and DCAM / DLM are two features that will trigger the
content pipeline. I don't remember the others.

On 7/26/06, David GOPOIS <david.gopois@interface-sa.fr> wrote:
> The fonts print if I do a screen print (Print Editor View).
> The fonts don't appear in Print Preview and in a PDF file.
>
> David GOPOIS
> Responsable Informatique / Computer Manager
> Tél.: (+33) 02 35 12 33 66
> Fax: (+33) 02 35 12 33 67
>
> Groupe INGELIANCE
> INTERFACE
> 230, route de Préaux
> 76160 Roncherolles sur le vivier - FRANCE
>
> -----Message d'origine-----
> De: Lynn Hales
> Envoyé: mercredi 26 juillet 2006 14:07
> À: adepters@arbortext.com
> Objet: Re: problem of specific fonts with print composer
>
> David,
>
> Do the FOSI fonts print if you do a screen print (Print Editor View)? If
> they are changed then, does the printer support the fonts you have
> selected? Try it in Macro$carf Word (or some other better word
> processor).
>
> Do the fonts appear in Print Preview or if you have the capability, in a
> PDF file using the generic PDF printer driver?
>
> I would like to think that if the font is installed on your system, it
> would print as long as the printer supports the font.
>
> I guess this is one of the 'joys' (sic) of not having to deal with a lot
> of formal output (like Andy and Ed have to do). I don't get to 'dig into'
> the print process a whole lot. 😞
>
> Lynn