Release notes for MECCA 2000 version 4.05. Apr/26/2005 (4.05 is the first official update after v4.00) Fixed: 1. PS -- corrected a problem in build-char, where calls to OtherSubr index 3 or above could cause stack error, a standard condition when building outlines from a font file (PS). 2. Graduated spot color screen in the output EPS/PS file which, when processed by Distiller, can end up being CMYK process color component (PSgraduate.ps). 3. When preparing a newly installed Type 1 font for use with X11, some font features (e.g. isFixedPitch, italicAngle, etc.) were read from the PFB file. Per Adobe PostScript Level 3 Specifications, these FontInfo dictionary keys are optional, and so are now treated as such (psfxlfd). 4. External BMP file may be converted upside down (bmptoix). 5. Print/output processing from bcompose to EPS had an error where it tried to get TIFF thumbnail -- which is only valid if EPS output is directed from MECCA 2000 print dialog (print.tcl). 6. rdpswdth, the program that reads font metrics (in .AFM file) and writes character widths information when installing font, asserted the 3 space characters (thin, en and em) even for a Pi font. This has now been corrected so it will not mark up those 3 space characters for a Pi font (rdpswdth). When using a Pi font and needing a controlled space, customers are advised to use "change font" command to obtain the desired space (thin, en, or em) with a regular font, then restore back to the Pi font in use. Please note this only applies to new Pi fonts installed beginning with this release. Already installed Pi fonts still have the widths of those 3 space characters, and mark-up files prior to this release will still function as they have been -- unless of course an old Pi font is removed then re-installed again. 7. xtblmake, the translate table maker for each new installed font, truncated a font mnemonic to no more than 7 characters, where it should have been 8 characters or less (xtblmake). 8. Fixed a problem introduced in v4.00 where scaling text causes re-compose, but left behind other transformation settings (rotation angle, mirror) for the next new input text (m2kbin). 9. Corrected the pngtoix raster image converter program, where it did not handle transparent color index in an LUT based image (pngtoix). 10. bcompose (command line batch compose-to-printer utility) sometimes accumulated part numbers incorrectly (bcompose). 11. Updated jpeginfo script to relax check on JPEG frame code, so that different kinds of JPEG files can be examined properly (jpeginfo). 12. Layer -> Setup dialog had an incorrect "focus" setting, which caused X11 Badmatch error (layer2.tcl). 13. A follow-up fix to "Named Colors" support added in v4.00: traditional MECCA color numbers 600-700 inclusive have dual meaning: either as a gray value in a process job, or a density percentage in a spot job. Hence, when loading an old file into a MECCA now using named colors, old color 700 becomes "Process Black". MECCA now looks at the "m2kPrefs(force_spot_color)" (in prefs) flag: if it is set to non-zero, then old colors 600-700 are not matched against any existing color chart; otherwise the standard color-matching (and possible re-mapping) is performed. Please note it is still possible to get the colors "wrong" when loading in an old drawing file that does not contain any specs: for instance, a drawing file using color 700 to be "process color black", now opened with a MECCA using named colors, and m2Kdata(def_spec_type) set to "spot". MECCA will then show the color as 100%, not "Process Black". Or, an old drawing file had its custom CMYK definition, for example, set to 65% CYAN for color 630 (back in MECCA III days, customers could freely edit each color's CMYK make-up), and has no part definitions. The CYAN tint will, under forced spot density interpretation described above, now become gray! There is, unfortunately, no viable solution to preserve all old colors in the new "named colors" environment (m2kbin, fcplist.tcl, prefs). 14. Different window modes (process or spot) sometimes caused color value to change (fcplist.tcl). 15. Put in proper positioning of merge-form mulitiple text lines (galeyc, frmpos). New/Modified: 1. In batch markup, the FIGURE and MergeForm (MFORM) commands now accept the new "TYPE=NJPG" value, to signal that a "Native JPEG" image is being used. Such an image will be passed, when possible, "as-is" in the PostScript output (galeyc, typdrv, preview, m2kbin). Please note the following conditions: a. JPEG image must be in the form of Baseline JPEG, not Progressive nor with any other features (e.g. JPEG2000). This is because the PostScript defined JPEG decoder only works with baseline codes. b. Only PostScript Level 2 and above RIPs support such JPEG format images (FYI: for generating PDF, you can think of the RIP being a Level 3 device). c. Such a JPEG image is output in PostScript as an in-line data stream (with the "currentfile" operator), and so such a page cannot be made into any PostScript Level 3 "Form" object. d. For a spot color job not being printed as composite ("Part per Page") color, JPEG images will not be output. e. Because a JPEG image is a raster bitmap (without standard DPI information), on output it will fit (stretch or compress) to the WIDTH and DEPTH you specify in the mark-up. The XPOS/YPOS marks where you want the upper left corner of the image to fall on your page (same as with other types of figure). f. When such a page is composed to screen preview, the JPEG image will be expanded for display; thereafter printing such a page directly from "Project -> Print" will not contain any JPEG data. To retain the smaller JPEG data size advantage, we suggest that once you adjusted design/layout to your satisfaction by using compose-to-preview, run compose one final time, but compose it to printer (perhaps print-to-file). 2. The File (open/save) dialog has been replaced (dbox.tcl, m2kprocs.tcl, tclIndex). 3. OpenType CFF fonts are now supported. In MECCA, such fonts are treated as Type 1 font, and corresponding PFB will be generated by using the open-source 'cfftot1' program (part of 'lcdf-typetools' suite). There is also limited TrueType font support, by using another open-source software library: Freetype-2. The limitations are: a. TrueType font is sent, at print time, as a Type 42 font per Adobe's standard. However, most level-1, and some level-2, PostScript RIPs do not support Type 42 fonts. Customers must determine whether their equipment can handle such fonts. Generally, if the RIP is bona fide level-3, it can support Type 42 fonts. Otherwise, run a test and see. b. TrueType font outlines cannot be acquired via "Area -> Get Text Outlines" function. c. There is no rasterized bitmap display for text using such fonts (at small sizes). d. Because of c above, there is no "Sample" display for a TrueType font (in Master Font List). In this release, a TrueType font is taken to be MS TrueType (not the old Mac TrueType); and so it uses either MS Symbol encoding, or the MS Unicode encoding. Of all font types, only the first 225 codes (ASCII 32 through 255) are used; and if the font is not a Pi font, the Amgraf encoding vector is applied. Open-source software distributed/installed with this release: lcdf-typetools is placed in /usr/local/bin, and Freetype2 run-time library, libfreetype.so.9, is placed in /usr/local/lib. These are open-source projects that MECCA font installation and pre-processing make use of, but they are not part of MECCA software. Their version numbers, as distributed with this update, are: lcdf-typetools-2.26 (the suite containing: cfftot1, t1dotlessj, otftotfm, t1reencode, t1testpage, mmpfb, t1lint, otfinfo, mmafm, plus their respective man pages). Freetype 2.1.9 (with minor fix). Please see the updated /usr/mecca/misc/acknowledgment file for information about these open-source projects. (m2kbin, typdrv, ftversion, ftolg, otfconv, mkolg, t1install.tk, t1font.tcl, m2kseet1.tcl, PSencode.ps, cfftot1, libfreetype.so.9, acknowledgment).