bug? - color number of dimension styles change when using a different color table

I defined a dimension style in the TextDimStyles.dgnlib. I defined a color for the dimension lines (number 254)  and the text (number 0) in the 'Symbology' tab. Our Drawing Seed has a different color table attached to it then this TextDimStyles.dgnlib.

When placing a dimension line using the dimension style as defined in the dgnlib in a Drawing, it doesn't use the color number (0-255) as defined in the dgnlib, but looks at the RGB value of this number in the dgnlib color table, and searches the nearest RGB color in the Drawing Seed's color table. This means the color numbers change. 

This is just retarded since the color table is ment to create a visual difference between the numbers 0-255 (which are the real 'colors') and you use these numbers as 'colors' in the pen table to define the output color, not the RGB value in your color table.

I found out about this after a long search. I solved this by attaching the same color table to the dgnlib, which gives me the same numbers since the same numbers have the same RGB color, but it shouldn't work this way...

anyone else noticed this or had a simular problem elsewhere?

  • Colour Tables

    Color Tables exist because of limitations in early graphic display technology, going back two or three decades.  They allow a limited colour index (255 colours) to map to an arbitrary set of RGB colours.  When using a Color Table, recognise that the situation you find yourself in is a consequence of technology designed to solve early limitations.

    Color Books and True Color

    From MicroStation XM, you have been able to use true colours: 24-bit colours indpendent of a Color Table.  Given the huge number of colours you can define, MicroStation provides Color Books to help organise your favourite set of true colours.

     
    Regards, Jon Summers
    LA Solutions

  • Doesn't the fact they exist from earlier limitations kinda proves my statement the described behavior is not what you would/should expect?

    And the numbers of the colors are used in the pen table, so they should get the priority over the RGB color for display reasons?

    Windows 10 pro

    OpenBuildings Designer Connect Edition 2023 | 23.00.00.114

  • I think he's talking about the color table numbers that are used for example the pentable (print-output). It shouldn't matter which color they show, it's the number of the colortable that count's.

    Using different colortables (meaning: same numbers, but just different colors) in the dgnlib and the actual file where you put a dimension based upon that dgnlib: that's where microstation does a translation based upon the visual color, and not using the number from the color in the colortable...

  • Unknown said:
    Doesn't the fact they exist from earlier limitations kinda proves my statement the described behavior is not what you would/should expect?

    On the contrary, that's what you would expect.  There is no facility to support multiple Color Tables.  If you use a true colour in your DGNLib, then you avoid the Color Table issue. 

    However, I note that you use a colour index in your pen tables.  Since true colours don't have a colour index, you would need to consider carefully the implications of moving from a Color Table to true RGB colours.  Best to post a question to the Printing Forum about true colours and pen tables.

     
    Regards, Jon Summers
    LA Solutions

  • Michael is correct about what I mean. Here is what I do:

    • In TextDimStyles.dgnlib, I open the dimension style dialog (element > dimension styles).
    • In the Symbology tab, I define a color for the dimension style and text (I pick one from the 0 to 255).
    • I create a new Drawing using a seed file which has another color table attached then the .dgnlib.
    • When I use the dimension style in this drawing, the numbers change to another number. This seem to chose the number which looks the closest (in the color table, colorwise, like in wavelength, not as a number) to the color on the color table of the number defined in the dgnlib.

    I would expect since I chose a number in the 1st step, this is what I define no matter what color is attached to this number in the Color Table (which is nothing more then an onscreen help to see difference between these numbers 0-255). Output color doesn't have anything to do with the Color Table, since the Pen Table is the tool to define the output/look of the final print (paper or pdf).

    In the Pen Table, we can use the 'Map Design Colors' to define a print color for each of these 0-255 colors. So in the end, this number is way more important then the color in the Color Table, which is nothing more then an onscreen visual help when designing. 

    Sure you can define a true color in the 2nd step of my workflow, but this isn't the way it should be done, the output color should be defined in the color table, that's what it's for.

    Windows 10 pro

    OpenBuildings Designer Connect Edition 2023 | 23.00.00.114