WF3 and PDF creation

Good day:

We use the PDF creation button that appeared in one of the later builds of WF2. With WF2, it works very well, much better that printing to a PDF writer.

With WF3, PTC added a dialog box with some nice PDF options, like password and comments (stuff I don't use, but nice enough). The major fly in the ointment is the font handling.

If you choose "Use True Type", the output file is all nice and pretty with Arial, but the spacing is all screwed up. When WF3 decides to start another block of text, say when you insert a ° or ±, the PDF has a large space between. Also, dimensions are not quite spaced right.

If you choose stroked text, it will have the default WF font, but the width factor is all wrong and the titleblock look terrible.

Any advise other than rolling back to WF2? We *just* started to use WF3, so it should not be to terrible to switch back. I *might* d/l M010 and give it a try.

If it ain't broke.....

Cheers!

-- Doug Eicher Global/SFC Valve Corp deicherATglobalsfcDOTcom

Doug, first of all, you may have been confused about PDF creation with WF2 ~ it uses Distiller or similar, but takes care of it so nicely, behind the scenes, that you'd think some other technology was at work. However, everything in the universe, except Acrobat, uses some version or variety (e.g., ghostscript) of a postscript converter to produce a PDF. This may be a setup issue from when the program is first installed; more likely, it is a setting in config.pro that got lost with the new installation, especially if the settings files, like config.pro or config.win, were left in the default installation directories. Anyway, a couple options govern this and it's advisable to check how they're set. They can be indentified by doing a Find on 'pdf'.

As far as Pro/e's use of fonts is concerned, it doesn't, it is totally ignorant of fonts. It has been, for almost 20 years, through the whole GUI revolution, been lost in its own, self-devised, self-sufficient, superior proprietary world. It merely, at times, reluctantly acknowledges the outside world by making such regrettable allowances as for OLE objects. And that is the only way that Pro/e 'understands' anything about TrueType or Postscript fonts and type faces, in general. It knows nothing at all of point sizes, of the M-quad, of kerning, of font 'hinting', of line spacing or any of the other considerations that any desktop publishing system takes for granted. Outside of OLE objects, its own native method of dealing with fonts is to copy the outline, using an approximation involving many lines and acrs (and no splines, can you imagine approximating a spline-type font curve with arcs?).

Thus, font information is not preserved without an OLE type object to enforce it and actual font handling information depends entirely on the OLE server and printing from within Windows Print Manager. This might take care of your printing problem if your are printing something with an OLE object embedded.

David Janes