v6.47a (8/1/2008)

This version supports USB key under Windows XP and Vista 64 bit.

v6.47 (2/27/2008)

This version fixes very short arc (1 format statement grid) reported by Printar.

v6.46 (10/3/2007)

Fuji Japan reported a problem with the way with supported the SR command with negative values. This has been fixed.

v6.44 (9/16/2007)

We added support for Gerber files with format of 9 digits (For example 4.5).
We also improved the software to handle gerber files that used syntax we didn't support.

v6.43 (9/6/2007)

We added a new command line option -reverse which reverses the color palette for BMP only. This is independent of the -inverse command line option.

v6.42 (7/26/2007)

This version support RLE8 in conjunction with super sampling, i.e.
you may use the -rle command line option with -super:N for
N equal to 2, 4, 8, 16.


As an example


C:\WCAD\GBRIP\gbr2tiff.exe Layer02.gbr -274x -bmp:L01_in_s04_case3-rle.bmp 
  -super:4 -units:inch -dpi:5800 -wplot -0.8,-0.4 2.4,3.65 -status -ram:16 -rle 


generates a compressed RLE8 BMP file while 


C:\WCAD\GBRIP\gbr2tiff.exe Layer02.gbr -274x -bmp:L01_in_s04_case3.bmp 
  -super:4 -units:inch -dpi:5800 -wplot -0.8,-0.4 2.4,3.65 -status -ram:16 


generates an uncompressed BMP file


The uncompressed output is 19.9 MB while the compressed file is 233 KB.

This version now supports 2, 4, 8, and 16 bit super sampling, corresponding to 4, 16, 64, and 256 x reductions in resolution. All outputs are greyscale.
For TIFF and BMP the corresponding command line options are

 -super:2
 -super:4
 -super:8
 -super:16

v6.41 (7/17/2007)

This version now outputs the correct windowed data for -aw and -wplot commands. Previously the image height was padded to the nearest value of 8000/SuperSampleValue.

This version now supports 2, 4, 8, and 16 bit super sampling, corresponding to 4, 16, 64, and 256 x reductions in resolution. All outputs are greyscale.
For TIFF and BMP the corresponding command line options are

 -super:2
 -super:4
 -super:8
 -super:16

v6.40 (7/1/2007)

This version now supports 2, 4, 8, and 16 bit super sampling, corresponding to 4, 16, 64, and 256 x reductions in resolution. All outputs are greyscale.

For TIFF and BMP the corresponding command line options are
-super:2
-super:4
-super:8
-super:16

Note that BMP does not support 2 bits per pixel rendering. For TIFF output we have added -super:28 and -super:48, which are equivalent to -super:2 and -super:4. BUT the output reflects 8 bits per pixel rendering, i.e. 256 levels of greyscale. For BMP GBR2TIFF maps user command line options -super:2 and -super:4 to -super:28 and -super:48.

v6.38 (4/25/2007)

This version is USB enabled.

Gerber Rip had a rip error where a G36/G37 boundary gets connected to another G36/G37 boundary outside the field of view. Problem reported by Fuji Japan.

Fixes the issue where a zero width dcode is flagged as an error in the log file; before it was a warning.. Problem reported by Cisco.

v6.34 (11/20/2006)

Oblong apertures were not scaled properly when the X and Y scale were different. The problem was fixed.

v6.32 (10/18/2006)

Conflicts between some command line switches are now properly flagged.
-super command line option must come last and only used in conjunction with -tiff or -bmp, and some others. Before a warning would be issued, but execution would continue. Now, the user is forced to fix the construction of the command line..

v6.31 (10/15/2006)

We added two new command line options for GBR2TIFF.EXE, namely -dpx:N and -dpy:N where N is the integral factor of columns and rows removed from an "oversampled" image.
For example...

Consider the following example command lines:

1) C:\wcad\gbrip\gbr2tiff.exe icsxseed.gbr -274x -inch -aw -dpi:4096 -status -pack:pack0.tif 

2) C:\wcad\gbrip\gbr2tiff.exe icsxseed.gbr -274x -inch -aw -dpi:4096 -status -pack:pack_x3.tif -dpx:3

3) C:\wcad\gbrip\gbr2tiff.exe icsxseed.gbr -274x -inch -aw -dpi:4096 -status -pack:pack_y3.tif -dpy:3


If (1) is the nominal command line, (2) generates an image that is 3x narrower,
while (3) produces an image that is 3x shorter.

Row removal is much faster than the bit manipulations required to do column
removal. This could esily be made 2x or 4x faster using multi-threading on a multi-core, multi-processor machine. 

v6.30 (09/11/2006)

Fix a bug report from FineTrak (Fuji UK).

v6.29 (08/08/2006)

Narrow traces that are less than one pixel width would sometime drop from the output file. That of course depends on wether the Gerber Rip scan line fell on the trace or not.
We added a new option -fill which will always give you a one pixel line under the above conditions.

-fill:0 (default or old behavior)

-fill:1 (fills in "gaps" less than 1 pixel).

Potentially the option may produce surprising results and run much longer.

v6.28 (07/06/2006)

The conversion from a monochrome bitmap to grayscale bitmap could generate bad data at the edges between data bands. This has been fixed. [reported by Maskless Lithography]

v6.27 (06/25/2006)

Fuji Japan reported a problem where macros disapper in the presence of some transformations, i.e. mirroring and/or rotation.

This problem was fixed;it was the result of macros that were drawn far off 0,0 i.e. macro definition extents did not include the origin. When these macros were inserted into the main drawing and rasterization was to be done with mirroring and/or rotation, they were thought to be off the rendered image and dropped.

v6.25 (05/15/2006)

Fuji UK reported a problem where oblongs were missing. This has been fixed.

The problem was the result of a large macro that followed a dcode reference in a file with decode redefintions. The coordinates to the reference were corrupted as the result memory overrun in a shared memory buffer used by the GERBER file reader and a coordinate database.

Hitachi reported a problem in which a wedge was created in a curved path during a mirror and rotation. This has been fixed.

v6.24 (03/29/2006)

Gerber Rip didn't support a macro that was used as a draw with more than 2 points. This limitation has been fixed

v6.23 (1/24/2006)

Gerber Rip had a limit of 100MM aperture size. Fuji UK reported a problem with a file that had 2 donuts bigger than 100MM in size. This limitation has been fixed

v6.21 (11/8/2005)

You can now set a DPI with a decimal number.

User can now define a DPM value (dots per milimeter) or define a pixel size instead.
For example..
-dpm:500
Will translate to 500 dots per MM.
-pixelsize:0.001
Will translate to pixel size of 0.001 inch or mm based on your -inch or -mm command line options.

v6.20 (10/4/2005)

There was a problem with a circle draw I J values both identically equal to zero. The draw is converted to a straight line. This was fixed (reported by Fuji Japan #11).

v6.19 (9/19/2005)

Point removal of excess points generated an open figure. This was fixed (reported by Fuji UK).

An incorrect folded polygon caused an error in Gerber Rip. A new folded polygon repair was added BOOLDLL.DLL (reported by Fuji UK).

v6.18 (8/26/2005)

an optional gray scale output has been added. The gray scale output is calculated by first rasterizing at 8X or 16X of the desired output and using the number of "mini pixels" triggered to set a gray value. [Requested by Maskless Lithography]

v6.17 (7/2/2005)

The problem was related to the presense of an arc with a single unit of arc length. With a scale of 0.5 the starting and end points of the arc collapsed to the same point which implies an arc of 360 degrees which in turn painted over the missing flash. This has been fixed.

v6.16 (5/20/2005)

When the option "-rotate" is specified, the "S&R" command was not rasterized correctly. This has been fixed.

v6.15 (4/6/2005)

Gerber rip failed to support 8 bit characters - it is now supported.

Fixed a bug where circular data in a G36/G37 block in the presence of large non-isotropic scaling rendered incorrectly.

Fixed a bug where flashes near the border of a rendered window, were dropped because they were thought to be outside the plot window in the presence of rotation and mirroring.

v6.14 (2/14/2005)

Some Dcode definitions (the ones that were missing) were redefined. Normally, this is handled properly, but in this case no GERBER data appears between the initial definitions and the secondary definitions. This has been fixed.

v6.13 (2/10/2005)

Gerber rip was not able to handle a polygon that had 35000 vertices (7600 were arcs). This has been fixed.

v6.12 (2/08/2005)

This version fixes the last issue reported by Hitachi. A problem in a module that supports multiply defined Dcodes was fixed. This is module handles the case when Dcodes are redefined as in the case in customer file. It has nothing to do with regular Dcode i assignments or macros. The bulges that appeared have nothing to do with issues in the RIP per se, but in the Gerber front end interpretter.

v6.11 (1/25/2005)

The problem showed up when two unrelated and disjoint G36/G37 area fills were inadvertently connected as a result of windowing.

v6.10 (12/18/2004)

Extremely large polygons with arcs were not handled properly. This problem has been fixed.

v6.08 (12/8/2004)

Donuts with small radius were dropped at low DPI (360). This problem has been fixed.

Under some conditions, polygons with thousands of vertices were dropped. This problem has been fixed.

v6.05 (10/18/2004)

There seemed to be a spurious line across the field of an otherwise properly rendered image. This problem was a bug in the buffered reading of data as the reader transitioned from the 274X header to the actual GERBER data. The problem has not been seen before because in most 274X files rendered to date the header (including custom macro definitions resided within the first buffered read). This problem has been fixed.

v6.04 (10/14/2004)

There was a problem with SR's with scaling present. There was special code to handle scaling properly, however, the test to see if this code was to be used was inadequate when scaling was to be the same in both the X and Y directions. The old code produced the correct results with no scaling or with non-isotropic scaling, scaling in X is not the same as scaling in Y.

There was a problem in the extent calculation of flashes in the presence of mirroring in which square, rectangular, oblong, and thermal flashes would be dropped if the flash appeared near the image border.

There was a problem with PACKBITS compression that has been corrected. Compression was being done in place which assumes local compression ratios less than 1 (one). When spatial variations are high the assumption is not valid resulting in the compressed data over-running the data to be compressed which of course results a corrupted image. We have never seen this before and has been corrected. The advantage of the previous scheme was memory conservation (equal to a raster buffer size). Now the data is not compressed in place rather a buffer is allocated data is copied to it.

v6.02 (09/17/2004)

GBV_RIP now supports the raster Postscript format (PSII). It supports color and black and white output.

These are the command line options available with this version...

  -ps2:<eps_filename>

  -cps2:<eps_filename>

  -color:<primary_color_name>


-ps2 and -cps2 indicate that the output is to be encapsulated Postscript level 2.

-cps2 indicates output is compressed (RLE)

unless the -color option is used, output is black and white.

primary_color_name can take on the following values:

red, green, blue, cyan, yellow, magenta, black

GBV_RIP was not rendering correctly one of the customer files at high DPI (12000). he problem was the result of a clipping routine that produced incorrect output at the higher resolutions when passed polygon data that exceeded 10 inches in extent. The file extents are about 20 inches on a side. The clipping routine now protects against integer overflow while retaining full precision of the data passed to it.

v5.99 (07/28/2004)

GBV_RIP was dropping a 360 degree draw (donut shape) when the aperture was narrow and the DPI was low enough that there were only 1-2 pixels to draw it. This has been fixed. (Reported by Printar)

Corrected an integer overflow that occured when a Gerber file with 3.6 format was submitted. GBR_RIP has a max dynamic range of 8 places (i.e. 4.4 is OK, 4.5 NotOK) Autoranging is not yet implemented. Data in the last place would be lost. (reported by FFEI)

FFEI reported a file with small narrow lines running across it and missing or distorted area fills. This was traced to improper use of the G36/G37 area fill in the input file.

In one case a D02 (move with pen up) command was embedded inside of a G36/G37 block. GBR_RIP treated this as a pen down draw -- but the resulting polygon was bad. GBR_RIP now will close and fill the polygon if it encounters a D02 and start a new polygon after the D02 move.

In a second case, a G36/G37 block had "zero" area. GBR_RIP rendered this as a single pixel wide line. GBR_RIP now fully discards such zero area G36/G37 draws.

Drawing with a rectangular aperture did not work if the input data was transformed by rotation. This was believed to be fixed in 5.97 but further tests indicated it had not been fixed when no scaling was applied. (reported by FFEI)

submitting an empty Gerber file to the RIP (and failing to close the RIP DLL) would cause subsequent jobs to fail. This condition is now detected and the DLL will automatically close. (Reported by FFEI)

Submitting Gerber files with excessive dynamic range (i.e greater than 8 total digits) can cause the RIP to fail. The RIP is designed to support a maximum of 8 places of dynamic range i.e. 4.4 is OK but 3.6 is not OK.

Detection and autoranging will be incorporated into the next release. Reported by FFEI and various other users.

Drawing with a rectangular aperture did not work if the input data was transformed by rotation. This has been fixed. (reported by FFEI)

A very large contour with arcs as part of the boundary was not rendered correctly. This has been fixed.(reported by FFEI)

A draw command using custom apertures was not supported. In this version the bounding box of the custom aperture is calculated and this bounding box (typically a square or rectangle) follows the vertices of the draw coordinates.(reported by FFEI)

fixed a reported instance improper rendering of thermals.

Certain arcs were improperly rendered when: a) the IJ (center coordinates of the arc) was not consistent with the arc's starting and ending points and b) scaling in X and Y was applied anisotropically. i.e. Xscale not equal to Y scale. Under these conditions the computation for the ellipse that results from the anisotropic scaling could blow up. A new computation method has been designed that eliminates this possibility. (Reported by FFEI)

Fixes a memory leak that caused memory usage to grow if the DLL was executed over and over again. Reported by FFEI.

GBR_RIP enhanced to support the MI mirror command in RS274X.

GBR_RIP enhanced to support G36/G37 polygons with more than 100,000 vertices per polygon. Note: such files may not render on other photoplotters or load correctly into other CAM systems. (Reported by FFEI #38)

Fixes a rendering bug where extra pixels appeared near the arc. (Reported by FFEI #37)

The fix in V5.79 was not complete and still manifested itself under some conditions of rotation and mirroring. It has been put to rest now. (Reported by FFEI #36)

A dropped arc reported by FFEI (33) was the result of throwing away the missing arc during a prescreening process to see if data falls in the rasterization window (not a banding issue as originally suspected). This error never showed up before because the prescreening process positioned the arc incorrectly when BOTH -90 degree rotation and mirroring was applied. This has been fixed.

Pad positioning incorrect due to program not properly applying the non-isotropic transformations to SR (step and repeat) data. This has been fixed.

Fixed a problem that occured when an arc or circle crossed a rasterization boundary. (see 5.69a -- apparently that fix did not address all possible conditions.)

Files that included the SR command (step-and-repeat) and that were transformed by rotation and mirroring would drop or scatter the stepped data. This has been fixed.

Certain rectangular data entities were sized twice resulting in bitmap width and height that was too large by a pixel. Fixed.

If no arc interpolation command is present in the file (G75) the RIP assumed 360 degrees. This behavior has been changed -- the RIP now examines the IJ commands to determine if interpolation is 360 or 90.

Under some conditions applying a rotation to the data caused arcs to be rendered incorrectly.

Corrected a bug caused by loss of pen up/down state prior to and during a G36/G37 command. (reported by FFEI)

Corrected a bug caused by loss of pen up/down state prior to and during a G36/G37 command. (reported by FFEI)

Corrected bug in parsing and booleanizing custom aperture macros. (reported by FFEI)

gbr2tiffcb_bitmapinfo(long width, long height, unsigned long sizeinbytes)
gbr2tiffcb_progress(long percent)
gbr2tiffcb_status(char *status)
gbr2tiffcb_message(char *message)

This release has

1. has callback functionality; (look in source/lib directory of the GBR_RIP distribution for callback related code and documentation)

2. when using GBR2TIFF.DLL you must now provide GBR2TIFFCB.DLL with your executable

3. to make use of the callback functionality in GBR2TIFF.DLL you must supply the "-callback" command line option; this forces the execution of GBR2TIFF.DLL in "silent" mode, i.e. it will not pop up any messaging, and all progress, status, and messaging is handled via the callback functions. In the sample GBR2TIFFCB.DLL provided with the release all these messages are written to plot.log

4. GBR2TIFF no longer hangs when the number of strips is insuffcient to contain the TIF image. (Applies to Automatech output only.)

5. the default number of strips is 6, i.e. 0 - 5 (applies to the proprietary Automatech output only.)

FLEXLM licensing
GBV_RIP now supports FLEXLM license manager in floating license mode.

Large raster file support
GBR2TIFF.EXE and GBR2TIFF.DLL have large file TIFF packbits support; have achieved 5 Gbyte images (@ 12000 DPI) with 1 Gbyte disk files.

Better Speed
GBR2TIFF.EXE and GBR2TIFF.DLL TIFF packbits compression is done on the fly resulting in better than 4x speed ups.

Auto Rotation
GBRSPOOL now supports auto rotation, i.e. best fit to target image size.

Maximum layer support
Maximum number of internal RS274X layers increased from 256 to 1024.

Gerber spooling
GBV_RIP now supports hot folders. User can define a hot folder where you can place Gerber files for plotting. The GBV_RIP will constantly look in the defined folder (or folders) and rip the Gerber file.

BMP support for 4 and 16 bit greyscales
The program now supports BMP format in 2 (mono), 4 and 16 bit greyscales (16 and 256 "color" palettes).
Option added for Bosch in South Carolina.

Cutout in a rectangular flash
The program supports cutout in a rectangular flash. The front end now properly supports the standard 274x definitions of Round, Square, Rectangular, and Oblong decodes with voids.

Circular Data
The problem here had to do with some very small circular data, i.e. the radius of circular data as denoted by I J commands were much less than the grid defined by the DPI.

MACROs bug fix
This revision represents all the cummalative patches that were part of v5.63 as well as one bug fix that involved MACROs. When a MACRO became subject to a mirror operation it's extents were computed incorrectly. The behavior was such that the MACRO sometimes was dropped from the output. This has been fixed.

GBR2TIFF.EXE (v1.10)
1. gbr2tiff.exe (v1.10). It is intended to replace gbripmgn.exe and gbrplt.exe. gbr2tiff will create either a TIFF file or a raw bitmap. It is intended to be launched from a command line. It's usage can be generated by invoking gbr2tiff.exe with the "-h" command line option. By default it runs in silent mode (no dialog, no status) which can be turned off with the "-status" command line option. Even with the "-status" option gbr2tiff.exe will not wait for user intervention to close by default. To defeat this behavior gbr2tiff.exe should be invoked with the "-pause" command line option.

Invocation of gbr2tiff.exe is done in one of four ways, i.e. a transform file specification or plot window specification in conjunction with a GERBER file type specificaion:

a. [path_to_gbr2tiff.exe] [gerber_file] -274x -xf [transform_file]

b. [path_to_gbr2tiff.exe] [gerber_file] -apt:[acs_aperture_file] -xf [transform_file]

c. [path_to_gbr2tiff.exe] [gerber_file] -274x [unit_specifier] [plot_window] [dpi_specifier]

d. [path_to_gbr2tiff.exe] [gerber_file] -apt:[acs_aperture_file] [unit_specifier] [plot_window] [dpi_specifier]

In each case other optional command line parameters can be provided. For clarity

plot_window is denoted by -wplot xmin,ymin xmax,ymax

dpi_specifier is denoted by -dpi:DPI

unit_specifier is either -mm or -inch

The plot window model accomodates rotation, mirroring, and scaling. These and other command line options can be readily viewed by invoking gbr2tiff.exe with the "-h" command line option.

By default gbr2tiff.exe invokes gbrplt.dll with either the -274xbi or -274xbm command line options. These command line options force the booleanization of 274X aperture macro definitions. To turn this behavior off, gbr2tiff.exe can be invoked with the -bool command line option. The -274xbi and -274xbm command line options to gbrplt.dll turn on aperture macro booleanization for inch and mm data respectively. Booleanization is not performed when the gbrplt.dll is invoked with the standard -274x command line option. There is usually no performance hit associated with aperture macro booleanization.

2. The rasterizers have been fixed to provided improved status reporting. The progress status should always be monotonic increasing.

3. gbrplt.dll now supports aperture macro booleanization. The -274xbi and -274xbm command line options to gbrplt.dll turn on aperture macro booleanization for inch and mm data respectively. Booleanization is not performed when the gbrplt.dll is invoked with the standard -274x command line option. There is usually no performance hit associated with aperture macro booleanization.

4. A number of fixes to the gbrplt.dll have been incorporated; these all have to do with rotation and mirroring of the GERBER data. In GBRIP v5.60 the following data were either dropped, misplaced, and/or incorrected processed in the presence of rotation or mirroring:

circular draws

all data subject to an SR command

custom apertures

These errors were present even for rotations that were a multiple of 90 degrees.

Increase Macro Aperture Limit
Previous version limited RS274X Macro definition to 1000 internal apertures per macro.. This version has no limit per macro, but has a limit of 10000 apertures in total apertures.

Add -server option
By default, license is locked during plotting. (Previous versions release the license immediately at startup.)
Add -server option to release the license immediately at startup. (Old behavior.)

Custom Flashes Not plotted
Some custom flashes might not be plotted. This has been fixed.

Change Windows query function parameters
Added 2 parameters to the query function. One parameter is to force the output unit and the other is to return the extents unit.

Add unit control to plot window argument
Added the command line arguments -inch and -mm options to control the unit of -wplot window extents.

Added Quiet Mode option (Windows only)
Add -q option to disable progress dialog