Windchill CAD Worker Issue - Font not reproduced during publishing

[GiacomoS]

Version: Windchill 13.0

Use Case: A CAD model includes a feature whose geometry is generated from a text string that uses a particular font. Since the font isn’t installed on the CAD Worker machine, the worker silently replaces it with another font, giving an incorrect representation without any error notification.

Description:

Hi everyone,

I’m running into an unexpected behavior with the Windchill CAD Worker when publishing Creo Parametric models that contain text using a non-standard font. In our case, the model includes a feature whose geometry is generated from a text string that specifically uses this font. Since the font isn’t installed on the CAD Worker machine, the worker silently replaces it with another font. The publish job finishes successfully, but the resulting representation is incorrect and doesn’t match the original model.

What’s most concerning is that the issue isn’t clearly reported anywhere. The only trace is a single warning line in the trail file, but no error is raised, no notification is sent, and the publishing task appears to complete normally. As a result, incorrect published content can be generated without anyone realizing it.

We’re aware that the simplest fix this would be to install the missing font on the CAD Worker machine, but our IT department doesn’t allow this due to legal and cost-related restrictions, so that option is off the table.

I’d like to know if there’s any way to make the CAD Worker treat missing fonts as a real publishing error, or at least to surface the issue more clearly, maybe through some form of notification.

Any suggestions or experiences would be greatly appreciated: maybe someone has already run into the same problem. A colleague of mine also asked a similar question in the feedback section of a PTC Support article, but we haven’t received any answer yet.

A couple of boring details about our setup, just in case they matter: Windchill 13.0, Creo Parametric 10.0, Creo View Adapter 11.1.

Thanks!

[TomU]

It is critical that the CAD worker machines reflect the configurations of the end-user's machines.  It's not realistic to expect publishing to match if not configured the same way.  If that is not an option, then it is possible for end-users to manually generate the visualization data as part of their save and check-in, but this will be missing other additional files that the workers may be configured to generate.  The Creo View Adapters are simply using the CAD software (Creo in this case) to do the publishing.  If the CAD software doesn't throw a fit about the issue (missing font), then I don't think the CAD worker process is going to even notice.  Your best course of action is probably to open a support case with PTC and ask them directly.

[avillanueva]

Agreed with @TomU . If this is branded font for your products, that should be justification for IT to allow the font to be installed. What kind of costs are we talking about here? I also cannot legal concerns as this seems to be legitamate use of the font. Did the designer who added the font go rogue and they should have used a standard font? Short of that, I would suggest the Windchill ideas board to submit something but honestly, I think it will be given a low priority.

[Marco_Tosin]

Hi @Tom and @avillanueva,
Giacomo works with me and we are both part of the company's IT department as well as being Creo and Windchill administrators 😁

A few clarifications regarding what you wrote.

The users' config.pro and the CAD worker's config.pro are the same, and all users who use it for design have the font in the Windows font folder on their PCs.

We discovered the problem because one of our mold makers received an order to build a mold, having shared the family table instance with him, which was missing the extrusion feature that used the font missing in the worker, thus creating the mold without the lettering.

The font was chosen by our marketing department to reproduce the code of our finished product on the molded parts.

The cost of the font used by dozens of users is very low, while the license to use it on the worker would cost tens of thousands of euros, so we are currently looking for a way to intercept the problem before spending a substantial amount of money.

The peculiar thing about the problem was that the family table had two instances, but only one was missing the extrusion of the text, while the other had it.

After several tests with one of the Creo experts, we discovered another peculiarity, namely that the correct instance during model regeneration had this warning in the trail file:

Warning “This view has been frozen because of illegal view instructions.”

There is an article that explains the reason for this

https://www.ptc.com/en/support/article/CS272516

The regeneration of the instance where the font was missing did not have the same warning.

The first idea that came to mind was to modify the worker configuration by adding the font missing error code to the error codes that cause the publication to fail, so that the printer cannot see the incorrect representation in CreoView.

I have already written a comment on an article that contains a list of some error codes used in the configuration, asking support if there is a list with this information, but I have not yet received a response after a week, so we turned to the community.

[avillanueva]

I suspected it was something like this. Have you tried with this specific model, doing a client side publish and checking that in? This would use the font installed on the engineer's system who generated the model and avoid the CAD worker touching it? Another option is to setup one of the engineer's systems as a CAD worker, specifically for this model and other like it.  I like option 1 the best.

[Marco_Tosin · Accepted solution]

Last night, I received a reply to my comment on the article I mentioned above.

The technician's recommendation is to open a support ticket.

In the meantime, we tried using Model Check, which is a new tool for us, to intercept the font error, and we succeeded.

Today, we will try to see if we can also cause the publication to fail.

UPDATE: Not part of Windchill PDMLink functionality

https://www.ptc.com/en/support/article/CS416262

[avillanueva]

Interesting solution. So you right now you are looking to just block publishing or cause it to failed if you encounter this font issue. How many models are impacted by this?  Would it make sense to just block publishing for those items?

[Marco_Tosin]

Failing the publication is a solution we have considered to prevent mold makers from having the wrong representation of the instance.

Unfortunately, it is not possible to use Model Check to cause the publication to fail (see my previous updated comment).

We may open a support case next week, but it would be complicated to manage because support would also have to work with an R&D colleague for the practical part of modeling and testing.

At the moment, the problem has only occurred once, but we do not know how many other models could be affected.

[TomU]

---

@Marco_Tosin wrote:

The font was chosen by our marketing department to reproduce the code of our finished product on the molded parts.

The cost of the font used by dozens of users is very low, while the license to use it on the worker would cost tens of thousands of euros, so we are currently looking for a way to intercept the problem before spending a substantial amount of money.

---

Seems like someone needs to have a chat with marketing.  😉

If the CAD worker is running under a single user account, does the font really need 'server level' licensing?

[Marco_Tosin]

My IT colleague who is an expert on licensing says yes.

[GiacomoS]

Hi @TomU and @avillanueva 

Thank you for your for your insights and considerations. In the end, we may open a support case to see whether there is anything that can be done on this issue.

Best regards,

Giacomo