When Using a PEN or DSCRIPT File, Overrides Are Not Respected

So, I've been testing the ever living $&%* out of this and I have been able to confirm 100% that if you are using a PEN or DSCRIPT file when printing, and an element has a linestyle applied directly to it (the element isn't ByLevel) then any override for that level is ignored for that element when plotting and it prints with whatever linestyle is applied to it. This even happens for text if the text has a linestyle applied to it.

I only discovered this because we do not use PEN or DSCRIPT files in our usual day to day plotting since linestyle stroke lengths can be controlled inside of the PLT or PLTCFG files, but we started using iCS for PDF to create Renditions in ProjectWise and iCS can not use PLT or PLTCFG files and all your linestyle stroke lengths have to be defined in either a PEN or a DSCRIPT file.

Does anybody know of any way around this or has anybody else encountered this? I'm desperate.

Thank you,
Chris Williams

Parents
  • The .pltcfg line style on/off pattern functionality can be perfectly replicated in a design script using the "style_1", "style_2", ..., "style_7" global assignment keywords. Since iCS for PDF is based on InterPlot, which does not use .pltcfg files for customization, a design script is needed to change the default on/off patterns. It is confusing that (due to historical reasons) InterPlot uses the ".pen" extension for what's now called design scripts.  But you can name the file whatever you like.

    Search docs.bentley.com/.../GUID-F84A1B3C-EB9F-8290-35F6-CC0762896755.html for "style_n".  Note that this is different from the "style" keyword (without the _1, _2, etc. suffix) used for per-element resymbolization.

    You can ignore the "if then else" logic in the example; that's just to show it's possible to define different sets of global line style on/off patterns depending on paper size. To replicate what's in a MicroStation .pltcfg file, all you need is just one set of "style_<n>" assignments at top of the design script after a "units" assignment.

    If you are not using pen tables or design scripts in MicroStation printing, then likely the design script needed for iCS for PDF would need to contain *only* those lines. The design script file would need to specified in an InterPlot .set file, which would then be associated with a ProjectWise rendition profile by the PW server admin.

          
    .

  • Andrew,

    Thank you for the in-depth response. The link does not work and tells me that I am unauthorized.

    Your answer explains how to get the on/off linestyles that are defined in the PLT/PLTCFG file into iCS since iCS does not use PLT/PLTCFG. I already knew how to do that and have already created the file you are describing in both PEN and DSCRIPT forms and had already applied them to iCS using a SET file. I stated this above in my initial question.

    My issue isn't creating them, it's the behavior change of printing an element that has a linestyle applied directly to it when you are trying to print with a PEN/DSCRIPT file applied. This is true in MicroStation printing and iCS.

    Luckily I posted this exact same question in the ProjectWise Plotting forum and someone there understood the question and responded about the behavior and not how to create PEN/DSCRIPT files.

    The issue lies in the variable IPLOTSRV_DESIGN_SCRIPT_SYMBOLOGY_AS_STORED when printing with iCS and how it grabs the linestyle from the header and not the override of the level. I do not know what the variable would be for local MicroStation printing but the same behavior is there. If you know what the variable is for local MicroStation printing I would appreciate it.

    By setting IPLOTSRV_DESIGN_SCRIPT_SYMBOLOGY_AS_STORED = FALSE it seems iCS picks up the level override instead of the element symbology like you would expect it to. The variable comes by default as TRUE and i was able to set it to FALSE in the Managed Workspace.

    Hope this helps you in the future.

    Thanks,
    Chris Williams

  • MS_PLT_DESIGN_SCRIPT_SYMBOLOGY_AS_STORED=0 may be what you are looking for, but no guarantees.  Writing conditional logic testing on the symbology in the element header is generally more reliable than testing on whatever symbology is actually displayed in a particular view -- which can be influenced by level overrides, text styles, display styles, display rules, reference adjustments, application-defined rules, and other features that have crept in over time complicating resymbolization.

          
    .

    Answer Verified By: Robert Hook 

  • Andrew,

    Thank you, that is indeed the variable for local printing. We are now covered for local and iCS printing.

    Thanks,
    Chris Williams

Reply Children
No Data