This version fixes an issue when an SR directive with non-unity X and/or Y values precedes end of data (M02) and there are no drawables between the SR and
M02 directives. The problem manifest as outputting data preceding the SR directive.
Now LP and SR directives are ignored if drawables do not appear between them and end of data. This fix is a more a robust fix to
that attempted to address the same problem in the previous version v8.13a.
Since GBR2TIFF v7.65 19 May 2021 GBRPLT by default converts round ended arc draws with width as outline data. In the event that the half
width of the arc is equal or greater than the arc radius a simple minded approach to generating the outline data can result in a convoluted
and/or illegal polygon.
Additionally special attention is required if the ends of the arc overlap even if the aforementioned condition does not hold.
With v7.65 a special algorithm was developed to avoid generating illegal polygons in these conditions. This algorithm was enhanced to better address polygon generation when customer found incorrectly constructed output.
Fixed an issue when an SR directive with non-unity X and/or Y values precedes end of data (M02) and there are no drawables between the SR and
M02 directives. The problem manifest as outputting data preceding the SR directive.
Now LP and SR directives are ignored if drawables do not appear between them and end of data.
This release fixes an issue in multi-window mode associated with SR data in the presence of scaling.
This release fixes an issue in the Gerber preprocessor (split274x) which was manifest as in incorrect tool select. The Gerber preprocessor is more than a simple Gerber interpreter in that in addition to fixing things that are "not nice" it also produces an optimized output where data in LPD and LPC data may be reordered in the output (e.g. fill data is collected and output at the end of an LP block). Additionally, GBRIP is hard coded to call split with -output_arc_draws (i.e. arcs with width are converted to fill data). This has been the policy in GBRIP since v7.65 release 19 May 2021. In the problem customer file the optimization code picked the tool associated with the previous flash D61 rather than D50 when converting the arc draw to a filled area.
Incorrect layer polarity presented itself for the last nonempty internal
layer of a Gerber file when the layers that followed it were only
populated with round flashes of zero dimension. The Gerber preprocessor
handled these internal layers correctly by removing these records
leaving those layers empty but this confused the importer in GBRPLT DLL.
GBRPLT now invokes the split preprocessor with a "-keep_zero" command
line option which tells split to not remove these records. The output
from GBRIP is correct. The "-keep_zero" feature was an existing facility
in the split preprocessor.
A problem was reported such that when using the GBRPLT DLL some log
files could not be deleted because these files created by the split274x
Gerber preprocessor were not closed.
In addition to this issue, a memory leak in the Gerber preprocessor associated with a boolean function
(window break) was fixed.
These issues would not be apparent in the use of the EXE version of GBR2TIFF.
The behavior of SR span tolerance was changed in the Gerber preprocessor (split274x). Where in previous versions there was by default a test for the displacement of the extremal drawables in an SR block from their "ideal" position, now this check is turned off by default.
It may be turned on by passing the command line option -enforce_sr_span_tol to the split274x Gerber preprocessor in the same way one would pass the control -sr_span_tol:value[unit], as an argument between -bgn_split_args and -end_split_args.
The default span tolerance is 1 um - this has not changed. Additionally, messages to stdout and/or the log file in this context were changed and (hopefully) are more understandable. SR span tolerance "violations" are now treated as warnings and only hard errors if -enforce_sr_span_tol is invoked.
GbrRip 64 bit now supports up to 4M internal paint and scratch layers. Previously only 1M layers were supported which resulted in unpredictable behavior including no output when the input Gerber file had more than 1M layers. The 32 bit version still only supports 1M internal layers.
Negative Dcode Dimension
When the use of -dcode_adjust would generate a standard Dcode with a
dimension less than zero, this Dcode will now have a dimension of zero.
For example, in a customer use case the size of a round Dcode in the ADD
directive was negative after using -dcode_adjust.
The software now changes such aperture from %ADD93C,-0.00001*% to %ADD93C,0*%.
The presence of Dcodes with negative dimensions as output by the Gerber
preprocessor would cause GBRPLT to exit without creating an output..
Fixes the broken functionalities introduced in v8.08 which addressed customer complaint about spurious extra pixel in line round tool draws (line widths ~20 pixels) when -dcode_adjust was used. Although v8.08 passed GBRIP regression testing, a problem became manifest for large width draws (> 500 pixels) for certain combinations of isotropic and non-isotropic scaling and rotation. The code changes introduced in v8.08 were developed under customer test conditions which only included unity scaling for narrow line widths.
This version fixed an issue where the rasterizer was snapping up when calculating the number of pixels in a round draw which sometimes resulted in an extra pixel along the width of a round draw. This was addressed by passing a non-rounded (double value) dcode tool width to the appropriate function in GBRPLT.DLL. Previously a rounded ((int) (toolwidth/grid+0.5) tool width was being passed and this value became quantized again (and sometimes it was rounded up) with the result that sometimes the output path width was 1 pixel wider.
Fixed an issue where the output for -slant_adjust was incorrect for very shallow lines (angles that deviated from horizontal less or equal to 0.04 degrees). The threshold for shallow line behavior adjustment was changed such that shallow lines in this range were treated as they were before "-slant_adjust" was introduced (i.e. output in this regime is consistent with old behavior - version 8.03 1/10/2022).
Compensation (-contours)Fixed an issue with an output deviations of 1 to 2 pixels from expected width for 45° and 135° diagonal lines. It turns out that these diagonal lines were not traces but actually polygon data. It was expected that the -contours option would address this issue but the flow associated with -contours (compensation) was inconsistent depending on how the RIP was invoked (i.e. with use of transform file (-xf) or auto window (-aw) or a prescribed window (-wplot)). This has been fixed. Now all three flows produce the same expected output.
A pad was dropped because the Gerber preprocessor was confused by the presence of G55 codes.
The notes from "The Gerber File Format Specification Revision 2019.06" in section 7.1 Deprecated Commands reads: G55 / Prepare for flash. This historic code optionally precedes D03 code. The problem was fixed by filtering out the G55 codes as the file was read.
Execution where pathnames exceeded 128 characters could result in a crash. Now the limit is WIN32 limit of 260 characters.
Width Corrections for Round Ended Linear Drawsv8.05 introduced corrections for round ended linear draws when the slope of a trace was between -20 and 20 degrees. This new behavior was not switchable. With v8.06 this behavior is now OFF by default and can be turned ON with the use of passing the "-slant_adjust" command line option to GBRPLT DLL. In GBR2TIFF this command line argument can be passed in the usual way as an argument to "-engargs" in which case it is passed downstream to GBRPLT.
This version fixed an issue with the new algorithm to better handle line widths with shallow angle (new feature which was introduced in version 8.04).
This version includes a new algorithm to better handle line widths with shallow angle (deviations from horizontal +/- 15 degrees).
Fixed a bug in the Gerber preprocessor that manifested as a extra pad under the following conditions: input Gerber file was IPPOS, the first internal layer was LPC, FS was "non-optimal" (not 3.5 for mm nor 2.6 for inch data, requiring reformatting) and the Gerber preprocessor was invoked with -outline_arc_draws which is the standard method as of GBRIP V7.65 5/19/2021. Data found on the first internal negative layer was treated as LPD - this was wrong and corrected.
New APIAdded API to GBRPLT.DLL to affect the rasterization of round ended trace draws. This new command line -dcode_adjust is passed to the Gerber preprocessor which in turn modifies entries in the embedded Dcode table of the input Gerber file. Usage of this new API is as follows (taken from GBR2TIFF.EXE help):
-dcode_adjust:VU[,D] compensate standard non-zero round apertures as per Value and Unit
Unit must be one of "um", "mm", "inch" or "%"
if Unit is "%" then it must be followed by ",Dpi" (suggested value for V is -10)
The following usages are all equivalent and will result in the same rasterized output:
-dcode_adjust:-0.05um, -dcode_adjust:-0.00005mm, -dcode_adjust:-0.000002inch, -dcode_adjust:-10%,50800Note that when the adjustment is given as a percentage then DPI must be part of the argument list. The value of V is signed, so a negative value will result in rounding rules such that path draws in pixels will be narrower than the nominal (i.e. no dcode adjustment). If V is positive then the rounding rules will be such that path draws in pixels will be wider than the nominal.
c:\wcad\gbrip64.v803\gbr2tiff64.exe test_mod.gbr -274x -mm \
-pack:50800_adj.tif -dpi:50800 -scale:1.0,1.0 -wplot -1,-1 1,1 \
-ram:2000 -logcalls -engargs -thrnum:2 -dcode_adjust:-10%,50800
c:\wcad\gbrip64.v803\gbr2tiff64.exe test_mod.gbr -274x -mm \
-pack:50800_adj.tif -dpi:50800 -scale:1.0,1.0 -wplot -1,-1 1,1 \
-ram:2000 -logcalls -engargs -thrnum:2 -dcode_adjust:-0.05um
Updated for the sample projects (located in "/source"):
Fixed a flow bug in the Gerber preprocessor when sizing is requested.
either-contours from GBR2TIFF or GBRPLT-dpi:N in the split274x command line when N is non-zeroNote: N < 0 indicates negative sizing, the amount of sizing being one half of 1/N where the units of N are in dots per inch.
Fully qualified 64 and 32 bit releases of GBRIP built on VS 2015.
Installer VS2015Installer also depends on VS 2015 redistributables.
Performance EnhancementVersion 8.00a exhibits improved speed attributed to change in compiler version.
This version has a new HASP keying routine for our OEMs. From this version on, there is no need to create specific version for each OEM who licenses GerberRip. OEM clients will be able to load and install the standard version along with a specific HASP DLL file which will be provided separately. This release was built with VS2008.
This version fixes a bug in the Gerber preprocessor when a D03* with no explicit X or Y values appeared immediately after an LP command and G36/G37 were present in the previous internal layer. Because the Gerber preprocessor rebuilds the input file including reordering of draw and area fill data to make use of multi-threading the lack of explicit X or Y values in the flash command caused a state problem in recording the correct position on output.
Now, by *default* all arcs drawn with a non-zero width round tool are converted to polygon data before rasterization by the Gerber preprocessor. This avoids this class of data being rasterized with specialized arc draw routines. On occasion these routines would generate spurious data or artifacts especially if the width of the arc was large compared to the radius, arcs crossed raster band boundaries or would terminate at nearly 90 or 270 degrees and other conditions.
Over the years these issues were addressed by breaking such arcs into safe sections and calling the arc generation in a recursive manner. Rasterization of the polygon representation of said arc draws are now handled by the area fill rasterizer. If necessary, the user has the option to go back to the previous rasterization model for arcs drawn with a non-zero width round tool with the -engargs option -outline_arc_draws or to pass -outline_arc_draws to GBRPLT.DLL. This is not recommended.
The new method produces smoother arcs for low precision (FS) Gerber files, is faster than the old approach and has been extensively tested as a module and in the product. The code for arc draw to polygon conversion has been in use in the ODB++ family of products and now has been added to GbrRip.
Super sampling *and* formatting of super sampled data is now multi-threaded. Previously it was single threaded and only mono-chrome images were formatted using multi-threading.
Big TIFFGBR2TIFF now supports Big TIFF.
Big TIFF is turned on with the -bigtiff command line option.
This version fixes the bug related to scaling in both directions that caused a gap in the output. This bug was tied to the fix introduced in v7.58 (the pad that was too big by one pixel).
v7.61 fixed a bug associated with round circular traces with included angle less than 360 degrees and vertices that might coincide
close to but not exactly ±90 degrees. The solution in v7.61 was to break up the arc by calling the out_arc function recursively but breaking the
original included angle into a number smaller angles such that the arc
path would start and/or terminate at multiples of ±90 degrees.
This version fixes a bug that manifested itself where a circular trace generated as just prescribed would be rendered with 360 degrees.
A simple check was added to protect against over-recursion.
Fixed the bug related to a round circular trace with a vertex that coincides close to but not exactly +/-90 degrees. The algorithm to draw the circular trace is "exact" but in rare cases (when there are perturbations caused by the 90 rotation) some numerical problems can be introduced and the result is a loss in fidelity.
This version has an improved way of handling square and rectangular flashes so that they align better with coincident draw data.
Fixed an issue where GBRIP outputs a flash that is too big by 1 pixel by treating rectangular and square flashes as polygon data.
In this mode, some flashes will be output as before but some will be smaller in
size (usually 1 pixel in one dimension) because of the enhanced/improved precision associated with these two apertures types in GBRPLT's
database.
The resulting size of course depends on DPI, whether the flash dimension is odd or even in pixels, scaling and snapping of flash center
in pixel world. At lower DPI's this enhancement is not important.
This feature can be turned off by using -flash2bndry as an argument to -engargs in Gbr2Tiff or as a direct parameter to GBRPLT.DLL.
Fixed an issue where GBRIP crashes when using two threads. This was caused by a draw that crosses raster boundaries. To fix this, the software handles these draws specially.
Fixed an issue where GBRIP failed because the input file has too many layers. We updated some 64bit modules to increase the maximum number of layers it can support. The 64bit release can now support input files that have up to 1048576 layers. The32bit release only support input files that have up to 262144 layers.
Pixel Compensation FixFixed an issue where the top part of the output is missing pixels. To fix this, we modified the library to add several pixels in the image length calculation and return the offset to the original row (for the first band).
Boolean LibraryUpdated boolean library to the latest (v2.645).
This version fixed an issue where the calculated image size snaps to the next/previous pixel unnecessarily. This was creating an image output that is 1 pixel larger than it should be. To fix this issue, we disable pixel snapping if the calculated image width/height is a whole number.
This version includes support for Flexera USB key and daisy chain licensing.
Software UpdatesFixed arc extent calculation. Extents defined fully or in part by circular data are now correct.
Fixed an issue where a file with many arcs created a polygon that
has more than 5000 vertices. This type of polygon is not supported by the plotter. These arcs are now segmented and split into several overlapping polygons.
Fixed an issue where multi threading creates a broken text stroke. This manifested because the input file has such a coarse resolution. In this release, the processor automatically converts these input files into the best format.
Fixed an issue where a macro was missing a hole when ripped. This was caused by a bug when cleaning up stale buffer with trailing garbage.
Fixed issue with thermal macro definition having nonzero angle parameter in the presence of mirror and/or rotation.
Fixed an issue where some SR data are not exploded. This was caused by a variable that is not properly reset because of format overflow.
Modified the code so that inverse is performed during plotting to improve timing.
Fixed the issue where multiple windows in MM unit are producing blank output on the 2nd and succeeding windows.
Fixed a bug where GBRIP failed to rasterize an input file with a large number of layers. The maximum number of layers GBRIP was raised to 256K in v7.42 but one of the intermediate modules was not updated - this was fixed.
The pre-processor now removes redundant and empty internal RS274X layers. This results in faster rip times as it reduces the number of database traversals.
Added threading to circularization for speed improvement during pre-processing.
Fixed a bug in the pre-processor where an optimization thats removes redundant macros caused the output to be truncated.
Fixed a bug for large round draws that straddle raster buffer boundaries. These paths were showing discontinuities at the raster buffer boundaries.
The pre-processor (split274x) is no longer inlined into GBRPLT.DLL but used as a library.
The header for TIFF files (both uncompressed and packbits) now reflect the usage of the -dpx:N and -dpy:M command line options which allows for pixel scaling by row and/or column removal. Details
This version augments the split274x (preprocessor/conditioning) functionality found in GBRPLT.DLL. To see the specifics please refer to the split274x page.
Includes sample code that illustrates use of the new split274x features
fixes an issue introduced in v742 that manifested itself as a stack-overflow crash
Multi-window mode was fixed for the special condition when either xmin or ymin was equal to 0 in a list of windows to be plotted (-wplot format xmin,ymin xmax,ymax).
Fine control of the Gerber preprocessor is now available from GBR2TIFF by passing arguments to GBRPLT.DLL using the -engargs command line option. An example of thread control in GBRPLT from GBR2TIFF is illustrated here
gbr2tiff64.exe icsxseed.gbr -274x -inch -aw -dpi:10160 -pack:out.tif -engargs -thrnum:2
Options to be passed to split274x must appear with those after -engargs, but encapsulated with -bgn_split_args and -end_split_args as in this example:
gbr2tiff64.exe icsxseed.gbr
-274x -inch -aw -dpi:10160 -pack:out.tif -keep_split!
-engargs -thrnum:2
-bgn_split_args -thrnum:8 -dpi:0 -chord_error:0.5 -circularize:1um -end_split_args
In the second example the first -thrnum:2 tells GBRPLT.DLL that two rasterizers are to be used, but 8 threads are to be used for polygon sizing and vertex control. These processes, rasterizering and conditioning, do not run concurrently.
Use Cases Showing Different split274x Options
We have two files in our working directory: a 274x file called NoShift.gbr and a batch/script file called NoShift.bat. We will show differences in cleaned output size that are produced using different options; the difference in processing time and the difference in the bitmap output (hopefully none).
[C:/wcad/Gbrip64.v743/EXAMPLES] ls -ltr total 94453 -rwxrwxrwa 1 win82\tester win82\None 48358866 Jul 13 18:09 NoShift.gbr -rwxrwxrwa 1 win82\tester win82\None 748 Jul 13 18:15 NoShift.bat
The contents of NoShift.bat
erase *.art /q erase *.log /q erase *.tif /q ..\gbr2tiff64.exe %CD%\NoShift.gbr -274x -aw -dpi:10160 -status -logcalls -ram:1024 -pack:std.tif -units:inch ..\gbr2tiff64.exe %CD%\NoShift.gbr -274x -aw -dpi:10160 -status -logcalls -ram:1024 -pack:keep_split.tif -units:inch -keep_split! ..\gbr2tiff64.exe %CD%\NoShift.gbr -274x -aw -dpi:10160 -status -logcalls -ram:1024 -pack:dpi0_maxpts.tif -units:inch -keep_split! -engargs -bgn_split_args -dpi:0 -chord_error:1um -maxpts:4096 -end_split_args ..\gbr2tiff64.exe %CD%\NoShift.gbr -274x -aw -dpi:10160 -status -logcalls -ram:1024 -pack:cir_2um.tif -units:inch -keep_split! -engargs -bgn_split_args -dpi:0 -chord_error:1um -circularize:2um -maxpts:4096 -end_split_argsWe then run the batch file
[C:/wcad/Gbrip64.v743/EXAMPLES] ./NoShift.bat
Comparison of Output Results
[C:/wcad/Gbrip64.v743/EXAMPLES] ls -ltr total 1440258 -rwxrwxrwa 48358866 Jul 13 18:09 NoShift.gbr [1] -rwxrwxrwa 748 Jul 13 18:15 NoShift.bat -rwxrwxrwa 146733149 Jul 13 18:18 std.tif -rwxrwxrwa 52191355 Jul 13 18:18 NoShift_split274x_20180713_181852.art -rwxrwxrwa 146733149 Jul 13 18:18 keep_split.tif -rwxrwxrwa 38616145 Jul 13 18:18 NoShift_split274x_20180713_181909.art -rwxrwxrwa 146733266 Jul 13 18:19 dpi0_maxpts.tif -rwxrwxrwa 11306528 Jul 13 18:19 NoShift_split274x_20180713_181925.art [2] -rwxrwxrwa 146712791 Jul 13 18:19 cir_2um.tif -rwxrwxrwa 22860 Jul 13 18:19 plot.log
Notes
1 The original RS274X file is 48.36 MByte
2 Using the circularize option the conditioned file is only 11.3 MBytes because many of the segments used to approximate curves were replaced with the circular command.
Timing Information
If we now extract from the log files the time required to rasterize the file we can also see the effect of the arguments.
[C:/wcad/Gbrip64.v743/EXAMPLES] grep Setup: plot.log | grep -v mm:ss Setup: 11, Rip: 07, Format: 00 Total: 18 (secs.) (std.tif) Setup: 11, Rip: 07, Format: 01 Total: 19 (secs.) (keep_split.tif) Setup: 09, Rip: 08, Format: 00 Total: 17 (secs.) (dpi0_maxpts.tif) Setup: 08, Rip: 07, Format: 00 Total: 15 (secs.) (cir_2um.tif)
Comparison - Conditioned Input with No Split274x
If we now take the conditioned RS274X file (the one that was produced using circularization) and run it through the rasterizer with the split274x operation disabled, we get the following timings.
../gbr2tiff64.exe NoShift_split274x_20180713_181925.art -274x -aw -dpi:10160 -status -logcalls -ram:1024 -pack:reused.tif -units:inch -engargs -nosplit
Setup: 11, Rip: 07, Format: 00 Total: 18 (secs.) (std.tif) Setup: 11, Rip: 07, Format: 01 Total: 19 (secs.) (keep_split.tif) Setup: 09, Rip: 08, Format: 00 Total: 17 (secs.) (dpi0_maxpts.tif) Setup: 08, Rip: 07, Format: 00 Total: 15 (secs.) (cir_2um.tif) Setup: 03, Rip: 07, Format: 00 = 10 Total (secs.) (reused.tif)[3]
Notes
[3] note that running the pre-conditioned input file with no split274x uses 3 seconds of setup time.
Output Bitmap Size
We can expect some very small differences in output file size. Since the size reported is after compression, very small differences in the size can be expected.
-rwxrwxrwa 146733149 Jul 13 18:18 std.tif -rwxrwxrwa 146733149 Jul 13 18:18 keep_split.tif -rwxrwxrwa 146733266 Jul 13 18:19 dpi0_maxpts.tif -rwxrwxrwa 146712791 Jul 13 18:19 cir_2um.tif -rwxrwxrwa 146712791 Jul 13 18:26 reused.tif
Fixed an issue in the buffered reading scheme for Gerber in GBRPLT.DLL. The problem is related to stale data (from previous runs or previous file reads) that resides beyond the end of an active buffer that coincides with "white space".
Too many layersFixed an issue where data was dropped because of too many Gerber layers. We increased the allowed maximum layer number to 256k in order to fix this issue.
Fixed an issue in v7.39 with GBRPLT.DLL when processing multiple files when encountering trailing zero (%FST..) or incremental (%FSLI...) Gerber files. The preprocessor which had a state problem was fixed. This issue would appear only if multiple Gerber files are rasterized one after another in a single run..
2GB Gerber filesAdded support for rasterizing Gerber files larger than 2GB.
Speed OptimizationAdded an optimization by avoiding re-interpretation of Gerber input files. This is achieved with the new optional argument "-keep_split" to the GBRPLT library in auto window mode. The pre-processed file is retained after computing file extents and then reused in subsequent calls. The caller of GBRPLT.DLL is responsible for removing this file.
Fixed issue where a "ghost line" appears in the output file. This was caused by an arc's invalid I/J value.
Fixed the issue where a single figure (G36/G37 block) where all digitized areas are connected by "cutlines" were dropped. The Boolean function that processed/repaired holes and cutlines was changed.
Fixed the issue where input with Negative Image Polarity (IPNEG) starts with a Dark Level Polarity (LPD) drops most of the data. We fixed this by reversing all the level polarities of the input file. Negative Image Polarity files must start with a clear polarity.
Bug Fix - Axis SelectWe fixed an issue where input has an axis select that assigns output device axis A to data axis Y, output device axis B to data axis X (ASAYBX) is not rotated properly.
Fixed issue where some arc was drawn with rectangle corner.
Bug Fix - Polygon ScalingFixed a bug where polygons were not scaled properly.
Updated the C# packaging, and added gbr2tiff debug DLL.
Macro ToleranceUser can pass arguments to split274x by using the following optional arguments in the gbrip command line:
-engargs -bgn_split_args [args for split] -end_split_args
For example, by default the tolerance to remove duplicate macro definitions is 1 um. If the user want to tighten this tolerance the command line above could be modified to look like the following:
gbr2tiff.exe
Inp.gbr
-274x
-mm
-pack:out.tif
-dpi:101600
-wplot 0,-45 50,45.0
-ram:256
-engargs -contours -thrnum:2 -bgn_split_args
-arcres:6
-macro_tol:0.0001
-end_split_args
Macros would have to differ by less than 0.1 um to be considered the same.
The C# application crash was fixed. It was caused by using a release version of gbr2tiff.dll from a debug version of C# application.
The Debug version of gbr2tiff.dll can be found in the "debug" directory at the install directory.
This debug dll can be used for development purpose.
An optimization introduced in v7.33 for handling full circles (circular data with the same starting and ending point) inside of G36/G37 blocks also introduced a state problem across internal layers in the handling of G36/G37 blocks while conditioning (split274x) the input Gerber file. This was fixed.
A customer reported a problem while compiling our C# example source code. It resulted in premature and unexpected program exit when the calling program makes use of GBR2TIFF.DLL. This bug was related to security/licensing and not the core program flow.
A previously introduced option, -contour, which made small compensations in Gerber traces to improve line width accuracy, proved to introduce a new problem when such traces shared an edge with polygon fill (G36/G37) data. The compensation to provide a more accurate line width could potentially leave a gap between the rendering of the trace and the edge of the filled polygon.
A new option, -drawadj, is now introduced, which will "grow" trace data to prevent such gaps.
It can be used in two ways:
-drawadj used without any following parameter, gbr_rip will automatically select an optimal amount of trace width growth based on the DPI; All traces are sized up by the same amount independent of the original trace width.
-drawadj:A the parameter A enables the user to control the amount of growth by value A (using the units specified in the transform file or passed on the command line). Again, all trace data is sized up by the same amount without regard to the original trace width.
This new option may or may not be used in conjunction with -contours (or -compensate)
The max Dcode value has been raised to 231
Interpretation of RS274X directives have been improved: some non conventional usages of the format statement (FS) are now handled "properly", at least as the user intended. Poorly constructed or unusable RS274X preambles are flagged as errors and rasterization will not occur.
-margin:L,R,B,T
where L, R, B and T are the Left, Right, Bottom and Top margins respectively.
The -margin directive and the autowindow directive (-aw) now are working together correctly. In previous versions, this combination did not always produce the expected margin values.
This is a monochrome (2 levels of "grey" black and white) but placed into a full byte (8 bits) for applications that only read standard grey scale input. It can be produced using the command line directive: -super:18.
This is consistent with the other super sampling options. The various options are shown in the table below:
| Command Line Directive |
Grey Levels |
TIFF bits/pixel |
Compression Options |
BMP bits/pixel |
Compression Options |
| None | 2 | 1 | U, PB | 1 | U |
| -super:2 | 4 | 2 | U | 8 | U, RLE |
| -super:4 | 16 | 4 | U | 8 | U, RLE |
| -super:8 | 256 | 8 | U | 8 | U, RLE |
| -super:18 (new) | 2 | 8 | U, PB | 8 | U, RLE |
| -super:28 (new) | 4 | 8 | U | 8 | U, RLE |
| -super:48 (new) | 16 | 8 | U | 8 | U, RLE |
Compression Options
U= uncompressed
PB = packbits
RLE = run length encoding
Prior versions did not work when more than one Sentinel USB key was inserted into a computer. This version now supports multiple USB keys on same computer.
A bug in thread control which was introduced in v7.27 was fixed. The thread control bug resulted from the fact that a global variable controlling the maximum number of threads was reset to "1" during file validation.
Missing FlashOur Gerber front end failed to handle specific Gerber code for a flash. This is now fixed.
In this version, the -contours command line option in GBRPLT.DLL treats circular traces with non-zero width differently.
In v7.26 they were segmented in a manner similar to circular data they might have been part of a G36/G37 block,
now in v7.27 they are output as circular data.
The motivations for changing the way circular traces with width were handled were two fold:
GBRPLT.DLL enforces a new policy that bitmaps need to be at least 8 bits wide and 8 bits high. If this condition is violated, this will trapped as load error.
A client reported long conversion time at 25400 DPI. We were able to improve the speed by performing a number of optimizations, including speed ups in the sizing algorithm in BoolDll and caching and reusing the results of sizing and window breaking data that were just translated in X and Y.
New Multi-Window Mode is available with GBR2TIFF 7.24 and GBRPLT.DLL - it supports multi-window raster image generation.
In this mode preprocessing, Gerber interpretation and database creation (in GBRPLT.DLL) happens only once per RS274X Gerber file.
Multiple raster images can be generated quickly without the latency of preprocessing or database creation.
In GBR2TIFF this facility is an extension of the –wplot command line option as seen here:
C:\wcad\Gbrip\gbr2tiff64.exe icsxseed.gbr -274x -wplot @wplot3.txt -dpi:5080 -status -ram:128 -pack:win.tif -units:inch
In this case the argument to the –wplot command line option is a text file in which each line contains two coordinate pairs as seen in the example below.
3,2,3.2,2.2 3.2,2.2,3.4,2.4 3.4,2.4,3.6,2.6
Adopted new Flexlm license model, and no more support for disk serial number.
Layer Name LimitFixes an issue where more than 4096 RS274X LN (Layer Name) directives appear in a file.
The limits was increased to be equal to that of the maximum number of internal layers 96K.
Supports the -contour argument to the GBRPLT.DLL setup function.
This new functionality compensates polygon data (G36/G37) by 1/2 pixel.
From the GBR2TIFF command line this option is passed to GBRPLT.DLL in the usual way by making use of the
-engargs command line argument. For example:
gbr2tiff.exe ....... -engargs -contour -thrum:4
In this mode split274x is called and a new Gerber file is always created with "optimal" format: 2.6 for inch and 3.5 for mm data.
As a point of reference split274x is always called (unless GBRPLT.DLL receives the -nosplit command line, which of course is supported via -engargs -nosplit to GBR2TIFF) to potentially condition the input to GBRPLT.DLL.
In the event it is found that preconditioning was deemed not necessary, the conditioned file is erased and the original file is submitted to GBRPLT.DLL.
This flow has been in place 2006 when it was first put in place to support files with multiply defined apertures.
This new functionality necessarily impacts throughput as negative sizing of polygons is computationally expensive.
A customer file with a 2 um round draw border exhibited several artifacts when rasterized at 1 and 2 um resolution. A similar file was constructed from the first one but the round tool was replaced with a square tool. Artifacts included:
This version minimizes the number of line widths and spaces associated with apparent traces.
Files with large number of macros or aperturesGerber Rip had issues converting Gerber files with over 10,000 apertures. This version has much improved support for files with large Dcode and MACRO counts. Optimizations are in place for redundant Dcodes and MACROs and nearly similar MACRO definitions.
Disparity between Round and Square DrawsGerber Rip generated square draws which were misaligned and sometimes wider from there round counterparts. This has been fixed.
This version includes a new command line option -aw:L,R,B,T where the autowindow mode is capable of providing margins on the Left, Right, Bottom and Top in the units provided on the command line (inch or mm).
Added sample source code to GBRIP 64bit package (including C#).
Fixed a problem with arcs that have very large radius.
Update libraries and engines (acsbool and gbr2tiff).
Fixed a bug that causes a crash.
Fixed Flexlm node locked licensing issue.
grey scaleFixed bug that causes an error when using -greylevel option.
Added C# sample program in the source folder.
Updated libraries included in the package. It will be installed in
instdir/Source/lib
Updated gbr2tiffshell.dsp and added gbr2tiffshell.sln which can be found in instdir/Source/shell4dll.
These will create the sample program gbr2tiffshell.exe in the instdir (install directory).
New HASP version (Fuji and Dynatron) of GBRIP 64bit.
First release of the 64 bit version of GBRPLT.DLL and the accompanying rasterizers.
On an average, the 64 bit version is 1.4 times faster than the 32 bit version.
The 64 bit version doesn't have the memory limitations of the 32 bit version.
There was a bug in the buffered reading module in which the last character in the buffer was dropped before refreshing the read buffer. This created a false vertical line that covers many cells in the panel. The issue has been fixed.
self-intersecting polygons in a Complex Aperture Macro was dropped. The issue was related to the latest boolean ACSBOOL.DLL and was fixed.
New -adnaseum command line optionA new command line option -adnaseum:N,M will repeat the same job N times and retain every Mth TIFF file.
c:\wcad\gbrip4fujijp.v705\gbr2tiff.exe -dpi:10160 -274x -mm
j02-204-02-2.gbr -pack:out.tif -ram:256 -scale:1.00055,1.0003
-wplot 8.64891,11.6739 550.151,633.486 -mirror:x -rotate:90
-status -adnaseum:1000,20 -engargs -thrnum:6
In this example 1000 RIPs are performed, and only files 0_out.tif 20_out.tif, 40_out.tif... are retained.
This version fixes the problem with stray line in multi-threaded operation where spurious data appeared at sub-band boundaries in the main band.
This version fixes the problem with running off the end of the region of interest in the rasterizer when multi-threading has been fixed.
This manifested as a crash or exception when the band size was short and the sub bands associated with threading were even shorter and data in the last band was sparse; short bands are the consequence of higher DPI for a given raster buffer size; short sub-bands are the result of higher thread counts, i.e. if one uses -thrnum:N then the sub band height is 1/N that of the band height.
In the past, this issue was only seen for 6 threaded operation at moderate values of DPI (less than or equal to 10000 DPI). This issue became important for at higher values of DPI used in conjunction with super sampling.
This version has protections against the creation of illegal output files (file sizes that would exceed 4GB).
Uncompressed BMP and TIFF file creation is checked at program start up, packbits TIFF is checked as the TIFF file is created (because the final output size depends on how compressible the image is).
This version reflects corrections and improvements to super sampling and uncompressed TIFF support:
This version now supports 96K layers. The memory footprint has been reduced in GBRPLT.DLL with respect to layer count.
fixes a bug in super sampling in conjunction with thresholding
Arc Issuefixed an issue with missing ball on arc.
This version fixes three arc related issues:
This version fixes an issue where the rasterizer incompletely renders the end of a arc with width (circular data trace) in the presence of 90 degree rotation (but not -90 degrees). This issue was manifest only in SR'd data for some user specified windows and the entire image. The problem was related to aliasing issues when mapping real world coordinates to raster data. This aliasing issue was addressed, specifically the arc start and end points and there corresponding angles were adjusted in the presence of aliasing.
This version fixes the issue when a polygon whose extents exactly coincide with raster band edges is dropped.
A complex macro with paint and scratch was incorrectly booleanized: a new version of BoolDll.DLL was required. This problem did not manifest itself with odd number of threads (1,3,5). With threading, the input set is striped and it happened that with an even numbers of threads (-thrnum:2 and -thrnum:4) a stripe boundary crossed several polygons with vertices coincident at the stripe edge. This has been fixed (issue 36).
Rectangular DrawA large ground plane made of up rectangular (not square) draws was not rendered correctly when 90 degree rotation was applied. The problem was a result of an optimization used to decide whether a path resides in the current band. With 90 degree rotation that wrong dimension of the rectangular trace was used to compute whether the trace was in the current band. This resulted in some traces being dropped. This problem also manifested itself as producing inconsistent behavior with different raster buffer sizes as this creates bands with different sizes and positions across the rendered image
This version fixed a problem reported in regards to image location and size issues in conjunction with super sampling.
In addition, -super:2 for BMP now support RLE encoding.
The new version improves performance by 3 times compare to the previous version in GREYSCALE and GREYLEVEL mode (this is true for high DPI). Run length encoding (RLE) speed is comparable to TIFF Packbits.
The new version supports up to 64000 internal layers.
Custom Aperture bugA bug related to custom aperture definitions was fixed. It was introduced during the effort to be able to load large layer counts.
This version fixes a bottleneck related to multi-threaded operation that was not noticed before. Previously some flashes were processed more than once in MT mode.
Memory Leak FixA memory leak related to thread handles was discovered and corrected.
Max internal layer count increased ...This version supports 274X files that contain in excess of 1024 internal layers (i.e. LPD/LPC changes); unfortunately the upper limit is limited due to 32 bit memory constraints. The maximum number of internal layers is file dependent, but lies somewhere around 10K. More work needs to be done here to achieve the target limit of 64K internal layers.
This version fixes a problem that occured when a very small window was specified for a gerber file using the SR command.
This version fixes a problem noted in -wplot mode in the tiff output.
This version fixes incorrect output triggered by an arc with large radius and almost 0 angle.
Multi-threaded raster output fixed for IPNEG
This version fixes a problem: raster output differed for files using IPNEG directive depending on whether multi-threading was turned on or off.
This version supports multi-threaded rasterization with up to 6 concurrent threads. Users can see major speed improvements especially when processing files at high DPI where the dominant bottleneck is the rasterizer. Note: Loading and polygon extraction is still single threaded and no speedup will be seen in those parts of the program.
The version fixes an error which was the result of a "degeneracy" caused by a cutline that "touched" a hole made from circular data in a large vertex count ground plane. This problem was fixed by removing the problematic cutline before converting the ground plane to its internal representation.
Extent calculation errorThe version fixes an extent calculation error for a donut shaped flash.
This version fixes a problem with a circular pad at 4.5 format.
This version fixes a problem processing a very "short" arc that is part of a G36/G37 block. The start and end point of the arc were so close that the RIP treated it as a full circle and therefore cut it away from the main polygon.
Integer overflow with shallow arcThis version fixes an integer overflow in the rasterizer for a shallow arc at high resolution.
This version supports USB key for the Gerber Spool utility.
This version fixes a bug report from Fuji which had to do with handling arcs at high DPI.
This version fixes the issue with a flash connected to an area fill - it was the result of a change made in v6.52 in response to another customer's request regarding the interpretation of codes in G36/G37 sequences. This fix caused the broken functionality reported by Fuji. The new code not only fixes the broken functionality introduced in v6.52 but also is an improvement over v6.51, i.e. it fixed some related issues that were previously undiscovered with respect to the interpretation of codes in G36/G37 sequences.
This version fixes the issue with dropped data due to an area fill denoted by a G36 G37 pair started with a move-to command D02 without any accompanying X or Y data; even though the front end treats the input GERBER stream as modal - it expected to see at least an X or Y value.
This version fixes a problem which resides in BOOLDLL.DLL in evaluating a macro.
This version fixes a problem handling a scaled oblong flash. This bug was introduced again in 6.49 when we fixed an issue raised by Fuji Japan.
This version fixes a problem handling a scaled oblong flash.
This version supports USB key under Windows XP and Vista 64 bit.
This version fixes very short arc (1 format statement grid) reported by Printar.
Fuji Japan reported a problem with the way with supported the SR command with negative values. This has been fixed.
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.
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.
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
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
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
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.
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.
2,4,8, and 16 bit super samplingThis 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:16Note 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
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.
This version is USB enabled.
Rip errorGerber 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.
Zero aperture DcodeFixes 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.
Oblong apertures were not scaled properly when the X and Y scale were different. The problem was fixed.
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..
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) gbr2tiff.exe icsxseed.gbr -274x -inch -aw -dpi:4096 -pack:pack0.tif 2) gbr2tiff.exe icsxseed.gbr -274x -inch -aw -dpi:4096 -pack:pack_x3.tif -dpx:3 3) gbr2tiff.exe icsxseed.gbr -274x -inch -aw -dpi:4096 -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.
Fix a bug report from FineTrak (Fuji UK).
Narrow traces that are less than one pixel width would sometimes be dropped from the output file. That depended on whether the Gerber Rip scan line fell on the trace or not.
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).
test this option carefully before using it in "production" as it may produce surprising results and run much longer.
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]
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.
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.
Wedge in a curved path during rotation and mirrorHitachi reported a problem in which a wedge was created in a curved path during a mirror and rotation. This has been fixed.
Gerber Rip didn't support a macro that was used as a draw with more than 2 points. This limitation has been fixed
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
You can now set a DPI with a decimal number.
New options - DPM and PixelSizeUser 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.
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).
Point removal of excess points generated an open figure. This was fixed (reported by Fuji UK).
Folded polygon errorAn incorrect folded polygon caused an error in Gerber Rip. A new folded polygon repair was added BOOLDLL.DLL (reported by Fuji UK).
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]
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.
When the option "-rotate" is specified, the "S&R" command was not rasterized correctly. This has been fixed.
Gerber rip failed to support 8 bit characters - it is now supported.
Circular data bugFixed a bug where circular data in a G36/G37 block in the presence of large non-isotropic scaling rendered incorrectly.
Dropped FlashesFixed 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.
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.
Gerber rip was not able to handle a polygon that had 35000 vertices (7600 were arcs). This has been fixed.
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.
The problem showed up when two unrelated and disjoint G36/G37 area fills were inadvertently connected as a result of windowing.
Extremely large polygons with arcs were not handled properly. This problem has been fixed.
Donuts with small radius were dropped at low DPI (360). This problem has been fixed.
Polygons with too many vertices droppedUnder some conditions, polygons with thousands of vertices were dropped. This problem has been fixed.
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.
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.
Extent calculationThere 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.
PACKBITS compressionThere 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.
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>
Notes
-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
GBR_RIP was not rendering correctly one of the customer files at high DPI (12000). The 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.
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)
Fixed Out of Range Gerber Input DataCorrected 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)
Fixed misc lines and corrupted figuresFFEI 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)
Failure when empty file is submittedsubmitting 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)
Out of Range Gerber DataSubmitting 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)
large boundary with arcs fixedA very large contour with arcs as part of the boundary was not rendered correctly. This has been fixed.(reported by FFEI)
draw with custom aperture macroA 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.
Improper Rendering of Arc data when using Anistropic ScalingCertain 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.
Lazy Pad FixedPad 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.
Sizing of Rectangular DataCertain rectangular data entities were sized twice resulting in bitmap width and height that was too large by a pixel. Fixed.
Detecting Arc InterpolationIf 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.
Arc Rendering with RotationUnder some conditions applying a rotation to the data caused arcs to be rendered incorrectly.
very large arcs (G02/G03) were not correctly rendered if they crossed a raster band. This has been fixed. (reported by FFEI)
Bug Fix - G36/G37 pen up/pen downCorrected 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)
Bug Fix - Custom AperturesCorrected 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
has callback functionality; (look in source/lib directory of the GBR_RIP distribution for callback related code and documentation)
when using GBR2TIFF.DLL you must now provide GBR2TIFFCB.DLL with your executable
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
GBR2TIFF no longer hangs when the number of strips is insuffcient to contain the TIF image. (Applies to Automatech output only.)
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