When exporting a parts drawing to a PostScript plot file from Pro-E,
is there a way to retain the part numbers as text instead of having
them represented as vectors?
If not through the native PS output, can the same be achieved via e.g.
a PDF printer driver product? What people then call 'searchable' PDF?
Thanks for any help you can provide. It may not sound like a big deal,
but it's important for a downstream spare parts application.
: When exporting a parts drawing to a PostScript plot file from Pro-E,
: is there a way to retain the part numbers as text instead of having
: them represented as vectors?
: If not through the native PS output, can the same be achieved via e.g.
: a PDF printer driver product? What people then call 'searchable' PDF?
The problem with pdf is that it is created, in this case, from the PS output.
Since the PostScript file contains only vector data, so will the pdf.
Have you tried STEP. It preserves text data. Don't know of a convenient, gui way
to access it, but my maybe Step Tools has come up with something clever. At least
try their website:
This was one of our main issues at the Wildfire 2 event last week;
i.e. the inability of Pro to handle TT fonts/OLE objects correctly.
Can't embed a spreadsheet correctly, and when using other than the
standard font PDF file sizes explode because of the rasterization of
the font. Though nothing concrete was assured, they of course had
heard this before and I got the impression something was being done
about it. I opened Pro/DESKTOP on my laptop and quickly stuck an
excel file into drawing mode and said, okay, this is Granite One as
well.......what gives? Why does the free PTC product handle this easy
task so well while the big-bucks product appears stymied?
Anyway, I hope this is something that will be addressed before WF2
hits the streets.
: Why does the free PTC product handle this easy
: task so well while the big-bucks product appears stymied?
Oh, now don't go asking that! There are just way too many comparisons in which
Pro/e comes off looking lame. But, it looks, from a comparison, that Wildfire
represents some attempt to catch up, to adapt some of PD's better features to
Pro/e more of a GUI modeller.
: Anyway, I hope this is something that will be addressed before WF2
: hits the streets.
Me too! It's been embarrassing for a while that many of the things which
distinguish Pro/e from other modelling packages have been some of the backward,
dorky, 'proprietary' features, like Amateur/TABLE (junky from Day One, not even a
respectable first year programming student's project and when invented, stood
by side with infinitely better Freeware database/spreadsheet programs.) And then,
we just limped along for many years, trying to do *everything* with it, while PTC
ignored requests for changes. That's what I really hope changes.
David, thanks for your response.
Are you sure about that? I'm not talking about distilling Pro-E's
native (vector) PS output to PDF. That wouldn't help, I know.
On Windows at least, printing a drawing "to file" to a PostScript
printer driver creates a different PS file than using Pro-E's own PS
output function, because the PS is generated by the (arbitrarily
chosen) printer driver. By that same rationale, products that can
create PDF straight from Pro-E would not use the native PS output.
Surely there are people out there who save their Pro-E drawings as
PDF, and do so via printing to Acrobat or some other PDF creation
tool. Maybe they can let me know if such PDF files can still retain
But I'm hoping that that doesn't have to be the case. I'm hoping that
there is a setting that can be changed so that the PostScript file
retains text as text. Something like 'embed fonts'.
A little background: I'm not the Pro-E user, my customer is. They want
to use our software to turn their CAD drawings into SVG format for a
spare parts application. Our software
is a batch conversion tool that uses
PS/EPS/PDF as input formats. Having the part numbers as text still
makes it easier to connect them to database info.
We routinely print ProE drawings to PDF, and we do it two different
1) Using ProductView's batch publisher. This creates a .plt file from
any files that change overnight in our Intralink database. The .plt
file is then run through an application called ViewCompanion, which
converts it to PDF (again in batch mode; you can buy this for about
$30). By the way, the text is not text in the plot file either,
evidenced to my when I was able to print Times New Roman Bold to a pen
plotter! What a racket, but it colored in the text. Real text would
either have returned an error or just printed the text in a default
font, but there is no way a 15 year old HP Draftmaster II could have
ever understood a True Type font. Ergo, it was NOT a font.
2) On the fly, using Adobe Acrobat's PDF Writer printer driver
(available in all Standard installations of Acrobat--not Reader, mind
you. BTW, this is NOT installed by default). We have a PDF .pcf file
set up in Pro, and then we use the Windows Printer Manager and specify
the PDF Writer (not Distiller). A tip: be certain to set the printer
resolution to 600 dpi instead of 'SCREEN'; this eliminates 'spiky'
text. The documents we print this way are exclusively text drawings
from Pro/REPORT (manufacturing info sheets).
In neither of the above cases is ProE's 'text' really text in any
sense of the word. You can't search it, you can't select it as text,
and you certainly can't use Adobe's 'Touch Up Text' functions on it.
And just looking at the screen and how the text is rasterize makes it
appear as if you will not be able to make it text ever. At least not
until PTC decides to change the underlying engine.
I did try once this crazy workaround, and it did work. Print the
drawing to a tiff file and then use OmniPage Pro to read it in and run
OCR on it. It worked, but was more effort than it was worth.