rasterized PDF and number of tiles

When doing a rasterized print in V8i, it now tells you that it's processing tile 1 of x, tile 2 of x, etc. What determines the number of tiles that it processes for each print?

We mostly print A1 size drawings, and depending on the printer driver, it's either 70 tiles or 280 tiles. That's a vast difference, with a corresponding difference in total processing time, and it also seems to have a bearing on final file size when generating a pdf. I'm in the process of testing out different pdf print systems and testing all the factors involved to try and minimise the file size while also generating a decent looking pdf.

Through looking at another thread, and one of Andrew Edge's marvellous printing exposes, I found out that changing the Bentley pdf driver from jpg to zip compression markedly improves the output, but also increases the file size eg from 3586KB to 5709KB. Interestingly enough, I then tried dropping the output resolution from 300dpi to 250dpi and ended up with a bigger pdf, at 6354KB.

If anyone can shed any light on these mysteries, I will be most appreciative.

Richard

  • The number of rasterized tiles is determined by the print size and printer resolution.  The graphics hardware used to rasterize the view is limited by its maximum display resolution, which might be 1600 x 1200 pixels on a modern system.  That's the largest image size that MicroStation can get out of the graphics card.  Graphics cards have different maximum display resolutions, so MicroStation uses a 1024 x 1024 pixel tile by default.

     

    Say you're printing to pdf.pltcfg (600 DPI) maximized to Arch D paper size (36 by 24 inches). The print size is 36 * 600 by 24 * 600 = 21600 by 14400 pixels. Divide by the tile size and you get 22 x 15 tiles, or 330 total tiles.

     

    As you can see, increasing either the print size or the printer resolution increases the number of required tiles exponentially.

     

    I can't explain why reducing the resolution would increase the file size.  That's counter-intuitive, and my experience has always been the opposite.  I would assume some quirky interaction between the number of the tiles and the amount of compression that can performed within each tile.   I suspect if you perform the same tests printing to uncompressed tiff.pltcfg, you would see a consistent, expected reduction in file size as resolution decreased.

     

    Be aware that the Optimize Raster Color Depth printer driver configuration property and the compression type affect each other.  When creating PDFs with LZW compression (the default), it's advantageous to convert true-color raster data (which is all that is emitted from the graphics hardware) to 256-color or monochrome raster when possible without losing data.  Thus, Optimize Raster Color Depth is set to True by default.  If you change the compression type to JPEG, reducing the color depth prevents effective compression.  In that case, it's better to set Optimize Raster Color Depth to False.

     

    You can read more about rasterized printing in this blog entry:

    http://communities.bentley.com/Other/Old_Site_Member_Blogs/Bentley_Employees/b/andrew_edges_blog/archive/2008/06/21/rasterized-versus-non-rasterized-printing.aspx

     

          
    .

  • Thanks Andrew,

    I think I have found a solution to using other PDF generators to speed up the plotting - setting their output dpi in printing preferences. Most of them let you change the resolution in the UI prior to saving the pdf but it doesn't make the actual print generation any quicker.

    Most of our stuff that we do to pdf uses gradient fills, so in that situation I don't think optimizing the raster color depth would be advantageous - or does it only optimize to 256 colours where it can?

  • MicroStation only reduces the color depth for each raster tile when possible to do so without losing any color information.  So gradient fills would be unaffected.  The effects of anti-aliasing can also produce tiles with thousands of colors from input data that is 256-color or less; those tiles will not have their color depths reduced.
     
    However, rasterized prints often contain many tiles that are completely white.  Those tiles compress well (using LZW) when reduced to 1-bit color depth.  The only good reason to disable color depth optimization is when using JPEG compression, which only works well with true color data.
     

          
    .