| Part# | 1161/21 |
| Build# | 11.1.14.686241 |
Upgrade from the Previous Versions and Releases
Binary Incompatibility
It is necessary to recompile host application regardless a version of Engine previously used.
API Changes
IRecognizerParams.detectLanguage property is marked as deprecated
New property IRecognizerParams::LanguageDetectionMode is now used instead of IRecognizerParams::DetectLanguage. IRecognizerParams::DetectLanguage is marked as deprecated.
For purposes of compatibility, new property value is changed whenever you change the DetectLanguage property: if you change it to TRUE, the property is set to TSPV_Yes, if you change it to FALSE, this property is changed to TSPV_No.
Some properties related to document structure are marked as deprecated
The following properties are marked as deprecated:
- IPageStructure::IsPageOdd
- IFootnoteSeries::HasSeparator
- IFootnoteSeries::PositionInDocument
- IFootnoteSeries::PositionOnPage
- IFootnoteSeries::IsNumberingWithSuperscript
- ISynthesisParamsForPage::InsertEmptyParagraphsForBigInterlines
These methods are not implemented and the implementation is not planned.
HFM_FORMAT32 format is marked as obsolete
From this release this format is obsolete. Using this constant is equivalent to HFM_Format40 with the IHTMLExportParams::UseCss property set to FALSE.
ICharParams::isWordStart is deprecated
ICharParams::IsWordStart property is deprecated and will be removed in the next major version. IsWordLeftmost property must be used instead.
Changes in behavior
Changes in language auto detection
In previous release property IRecognizerParams.DetectLanguage was set by default to FALSE.
In this release new property IRecognizerParams::LanguageDetectionMode is set to TSPV_Auto.
You can find detailed information about new IRecognizerParams::LanguageDetectionMode property in the section New advanced language detection mode.
pminliu and mingliu fonts are always embedded during export to pdf file
You can find detailed information in Correct display of PDF files with PMingLIU/MingLIU fonts in viewers section.
support of corrupted tiff files opening
Starting with this release, FineReader Engine can open corrupted TIFF files. It can be done only if one last line is corrupted, otherwise an error occurs and the corrupted file is not opened.
If the TIFF image which has been opened is corrupted, а warning message containing the number of the damaged page in the image file will be shown.
Higher obr accuracy in trade of speed
‘BarcodeRecognition_Accuracy’ processing profile became more accurate in exchange of slowdown. For details see ‘‘BarcodeRecognition_Accuracy’ became more accurate’ below.
New Features and Improvements
Screenshot detection
From now on, our technologies are able to identify screenshots in documents. The document analyzer detects screenshots as image blocks if EnableTextExtractionMode property set to false (it is default value). Otherwise, text blocks can be detected on the screenshots.
Improved key value tables detection
Significant improvements were made for key value tables’ detection in this release.
Possibility to add attachments to pdf
All the attachments are contained in FRDocument::PDFAttachments. You can add files to be attached to the output PDF file during export.
New property iprepareimagemode::backgroundfillingcolor to fill areas added after skew correction
After skew correction supplementary areas are added to the edges of document. The color of these areas is set automatically by Fine Reader Engine:
Now it is possible to specify the color used for filling the areas manually with IPrepareImageMode::BackgroundFillingColor property:
The default value of this property is -1, which means that the color is determined by ABBYY FineReader Engine automatically.
Possibility to see pdf layers in pdf viewers
A new property IPDFMRCParams::AssignPdfLayersToMrcPlanes was added in this release. This property manages the availability of PDF layers in the output PDF file. If you set it to TRUE, PDF layers are assigned to MRC image planes, so that in some PDF viewers such as Adobe Acrobat you can choose which layers to view:
This property is only taken into account for image-only and image-on-text PDF files.
The default value of this property is FALSE.
New method iimagedocument::removecolorobjectsex
This feature can be useful for documents with black text and white background that contain colored elements that don’t need to be recognized. For example, for monochromic documents with colored stamps only black-and-white layer can be recognized and the colored elements can be added to output document.
IImageDocument::RemoveColorObjectsEx method allows you to remove color objects of specified hues from original document
The hues of removed objects are set by HSL representation. The method allows replacing removed objects with the specified color. It also allows saving a separate image containing only the extracted objects:
New advanced language detection mode
New property RecognizerParams::LanguageDetectionMode was added on this release. This property will be useful for recognition of documents the language of which is not known to you. If language detection mode is on, the recognition languages are selected from the list of languages specified in the TextLanguage property. Language detection was significantly improved from the previous release and now it turns on automatically if it is necessary.
This property has three modes: TSPV_Auto, TSPV_No and TSPV_Yes. The default value of this property is TSPV_Auto. In this mode ABBYY FineReader Engine will automatically determine if this processing mode should be used, depending on the situation.
Auto detection will be useful only if TextLanguage set contains a combination of CJK and European languages. New feature will increase the speed and improve the quality of recognition for documents with European languages.
In the scenario when you know that all languages, specified in TextLanguage set, are present in the document, that you process, we recommend setting RecognizerParams::LanguageDetectionMode to TSPV_No.
Old property RecognizerParams::DetectLanguage is marked as deprecated.
New predefined filter fnf_pdf in fontnamesfiltersenum
FontNamesEnum enumeration constants describe predefined filters of font family names. These filters specify the set of fonts to be used during document synthesis. A new value FNF_PDF was added to FontNamesFiltersEnum. If this filter is applied, document synthesis uses font families the names of which are specified in the resources of the input PDF file. However, the fonts themselves are not extracted from the PDF file; they need to be installed on the workstation to be used.
Skew correction in prprocess stage
Now it is possible correct skew at preprocessing stage instead of during image opening.
CorrectSkew property was added to PagePreprocessingParams object. The type of skew correction is defined by the CorrectSkewMode property.
Advanced isemptyex method for checking if the page is empty
IsEmptyEx is a new method which allows you to specify additional parameters during empty page detection.
With EmptyPageDetectionParams object you can define the number of letters and text objects that a page can contain and still be considered empty. It is possible to set maximum black percentage and to specify if the page must be searched for barcodes. You can also set the page rectangle, so that any garbage on the margins does not affect the result.
A method IEngine::CreateEmptyPageDetectionParams was included in API to create the EmptyPageDetectionParams object.
Possibility to export tiff files with one strip
A strip is a subsection of the image composed of one or more rows. A TIFF image may be composed of one or more strips. Now it is possible to deliberately produce TIFF file composed of one strip by setting ITiffExtendedParams::WriteSingleStrip to TRUE. The parameters for TIFF files producing can be used IImage::WriteToFile method.
That feature was implemented as some archive writers don’t support valid TIFF files with several strips.
New property recognition set
A property ITextLanguage::RecognitionSet returns the full letter set used for recognition with this TextLanguage, combining all letter sets of its base languages and additional letter sets.
correction display of PDF files with PMingLIU/MingLIU fonts in PDF viewers
Now all exported PDF files with PMingLIU and MingLIU fonts are displayed correctly in all PDF viewers. Previously there were problems with display due to errors of some viewers. As a workaround these fonts are now embedded to the output PDF file.
Please note that if for a Chinese-language document the PMingLiU/MingLiU font is used, it will be embedded into output PDF file regardless of the value of the property IPDFExportFeatures::FontEmbeddingMode.
Information about adding comments in profiles in help file
The information and an example on how to add comments, were in the section Working with Profiles Comments can be added by starting a line with a semicolon.
Possibility to enable and disable interpolation in pdf viewers
Interpolation in PDF viewers can insignificantly affect the visual quality of PDF file. A new property IPDFPictureCompressionParams::EnableInterpolationMode allows to disable interpolation in PDF Viewers. The property has tree modes: TSPV_Yes, SPV_No and TSPV_Auto. Note that if the IPDFExportParams::PDFAComplianceMode is set to PDF/A, interpolation will be always disabled as it is required by specification of PDF/A format.
The default value of this property is TSPV_Auto, which means that the interpolation will be turned off for PDF/A-compliant formats and on otherwise.
New property IEngine::availablepredefinedlanguages
New property IEngine::AvailablePredefinedLanguages returns the collection of predefined languages that are available under the current license.
New property for shawdows and highlights correction in photograpghs
IPagePreprocessingParams:: CorrectShadowsAndHighlights property was added in this release. This property allows correcting excessive shadows and highlighting during image preprocessing. This property is designed for use with photographs only.
Three states are available: TSPV_Yes, TSPV_No and TSPV_Auto. By default the property is set to TSPV_Auto.
|
Before |
After |
New property ihtmlexportparams::usecss
This property determines if a separate style sheet file (.css) is created. In previous releases style sheet file was always created. Now it is possible to use built-in style sheet file by setting IHTMLExportParams::UseCss to FALSE.
The default value of this property is TRUE.
Possibility to improve recognition quality by removing color objects before recognition during preprocessing stage
This feature can be useful for documents with black text and white background that contain colored elements (for example, stamps) that don’t need to be recognized.
New property IPageProcessingParams::ProhibitColorObjectsAtProcessing allows filtering out color objects on the image before layout analysis and recognition. After processing is complete the color objects can be put back on the image again:
1.Input document contains color objects
|
1.Input document contains color objects |
2.Color objects are ignored during processing |
3.Color objects are restored in export result |
If this property is set to FALSE, the ColorObjectsProhibitingParams property is ignored. The default value of this property is FALSE.
A new ColorObjectsProhibitingParams object has been added. It is used for tuning parameters of filtering out the color objects on the image before starting processing. This kind of preprocessing can be useful in cases when the document to be recognized has color stamps, signatures etc., which can reduce recognition quality. The parameters are only taken into account if the ProhibitColorObjectsAtProcessing property is set to TRUE.
It is possible to specify in properties of this object the following parameters:
- the color which must replace the removed color objects
- the collection of the hues of the objects which must be filtered, in HSL representation.
- if, after processing is complete, the color objects must be put back on the image again.
A new property IPageProcessingParams::get_ColorObjectsProhibitingParams returns a ColorObjectsProhibitingParams object.
Another way to improve recognition quality by removing color objects is to use IImageDocument::RemoveColorObjectsEx method, added in previous release, but it doesn’t allow restoring color objects on the image again before export.
Possibilty to replace back or white color of exported png images with transparent
From now on it is possible to replace black or white color of exported PNG images with transparent:
A new object PngExtendedParams was added. This object provides functionality for tuning the parameters of saving a black-and-white image to PNG format (IFF_Png format) using the IImage::WriteToFile method.
To replace the color with transparent it necessary to specify the color in IPngExtendedParams::TransparentColor property. Only black and white colors are currently supported.
The default value of this property is -1, which means that no color will be replaced with transparent color.
New method iengine::createmultipageimagewriterex
The method IEngine::CreateMultipageImageWriterEx allows to set extended parameters of image saving (JpegExtendedParams, PngExtendedParams or TiffExtendedParams) when creating the MultipageImageWriter object.
New attribute ‘rotation’ in xml export scheme
New attribute ‘rotation’ in ‘page’ tag defines the type of rotation applied to original page image before processing. It can have one of the following values: Normal, RotatedClockwise, RotatedUpsideDown, RotatedCounterclockwise.
New property irtfexportparams::keeppagecreaks
IRTFExportParams::KeepPageBreaks property specifies if the page breaks must be retained in the output RTF document.
New profile for speed up of barcode recognition
New profile BarcodeRecognition_Speed was added in this release. It enables fast barcodes extraction.
New BarcodeRecognition_Accuracy profile is equivalent to the BarcodeRecognition profile available in previous releases.
In some cases BarcodeRecognition_Speed speeds up the processing almost by 2 times. However, it can decrease the recognition quality. Below you can see the changes in results of processing with the BarcodeRecognition_Speed profile compared to the BarcodeRecognition_Accuracy profile for some types of barcodes.
| Barcode type |
Speed up in BarcodeRecognition_Speed profile |
Lost in quality in BarcodeRecognition_Speed profile |
| 1D Barcodes, Code 128 | 14% | 10% |
| 1D Barcodes, Code 93 | 73% | 0% |
| 1D Barcodes, EAN 8 | 29% | 12% |
| 1D Barcodes, UPC-E | 116% | 0% |
| 2D barcodes, Aztec |
59%
|
50% |
| 2D barcodes, MaxiCode | 94% | 37% |
Tests were run on the machine with following configuration: CPU - Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz, Memory - 2.0 Gb.
New section in developer’s Help “predefined profiles specification”
The new section contains a full list of all settings used by ABBYY FineReader Engine predefined profiles.
Support of corrupted tiff files opening
Starting with this release, FineReader Engine can open corrupted TIFF files. It can be done only if one last line is corrupted, otherwise an error occurs and the corrupted file is not opened.
If the TIFF image which has been opened is corrupted, а warning message containing the number of the damaged page in the image file will be shown.
Exporting ALTO up to version 3.0
It is possible to export OCR data into ALTO format according to the following ALTO standard versions:
- 2.0
- 2.1
- 3.0
The default version is 2.0, same as it was in the previous release.
Memory saving in case of no need in coordinates on original image
Instruction IPrepareImageMode::KeepOriginalCoordinatesInfo = false tells the Engine not keeping image transformation matrix required for backward object coordinates calculation used for getting coordinates on original (source) image.
If there is no need in keeping the transformation data, it helps to preserve storage and memory space. For example, during processing of b/w images (~100Kb) the transformation data could be up to 1Mb per image.
Crop function supports greyscale and b/w images
Starting from this release it is possible to run ImageDocument::CropImage() function on greyscale and black and white images. Previously that was possible only for color images.
Fine tuning of paper size detection
The Engine is able to detect paper boundaries on a scan automatically (PageAnalysisParams::NoShadowsMode = false, default value).
This helps to rid of garbage detection as text near borders of a scan. In some cases, this detector can fail. For example, if a scanned document contains a big dark picture it might be taken as a scanning background and removed from a document area as a scanning shadow.
To prevent such mistakes a host application may advise the Engine to limit the scanning shadow detector hypotheses by providing information on what part a source document occupies on a scan.
API provides PageAnalysisParams::PaperSizeDetectionMode for this purpose.
Improved MRC quality
IEngine::Version returns the build number of the ABBYY FineReader Engine version you are using.
New property IEngine::Version
We improved all predefined MRC modes
The main target was to improve visual quality because predefined MRC modes available in the previous releases provide too low quality and our customers sent us many complaints regarding that.
MinSize predefined mode.
In exchange of 32-38% increase of a file size, you get 6-15% faster speed and significantly better document image quality:
| Old settings | New settings |
MaxQuality predefined mode
In exchange of negligible image size increase (~0%), new settings provide 2-11% faster speed and better visual quality for a document image:
| Old settings | New settings |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Balanced predefined mode
In exchange of 14-15% increase of a file size, you get 6-15% speed increase and significantly better document image quality:
| Old settings | New settings |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MaxSpeed predefined mode
In exchange of almost no file size increase (2-8%) new settings provide better image quality (see modes above) and noticeably faster processing speed (30-45%).
Convenient method for getting recognized word region
Many customers work with recognized words instead of recognized characters. In most of the cases, such customers need to highlight a word of matter in graphic user interface. The highlighting requires a word-bounding rectangle (region).
Since words may include characters of different height and could span several lines the task becomes non-trivial. To make it easy and facilitate our customers we added new property to IWord interface that returns a word-bounding region – IWord::Region.
Large document conversion to searchable pdfs at full throttle
Super multi-page document conversion to searchable PDF might be challenging task if your PC/Server has limited resources. This is resource intensive task and at certain point becomes a very long time consuming one.
Such tasks and issues are common for mid and big MFPs where one can put a big pile of papers and order a searchable PDF output. Similar scenario you can see in case of an archive conversion while the archive stores super-multi page ‘files’.
To provide a proper tool we added new API, and found the best usage scenario for FRE 11 and are introducing this in the R6 release product documentation: look for the article ‘Exporting Large Documents’.
The main advantages of the new usage scenario
- dramatic speed increase when exporting large documents
- less RAM resources required
- convenient error handling without losing all the exported data. In case of simultaneous export a single error may cause failure of the whole export stage. If you are processing a large number of pages, the restarting of export can take plenty of time. Now using the new functionality you do not have to stop processing. The errors can be caught and handled inside small portions. So export will be finished faster even if some errors occur during the processing.
Recommendations
- Using the new export mode is reasonable for documents which contain 50 pages or more. For 500 pages and more using ExportFileWriter is highly recommended.
- Export a fixed number of pages at a time. You will need to do some experimenting to pick the best number of pages for your documents. During internal ABBYY tests the portion size of 30 pages was found best for generic documents.
Japanese OCR improvements
Last year R&D and ABBYY Japan spent much time jointly in the project for improving Japanese OCR. The joint team identified and solved many issues. The project is not finished, but FRE 11 R6 contains intermediate result including the following improvements:
- Old Kanji characters issue. ABBYY Japanese OCR is capable of recognizing Kanji characters are not of frequent use nowadays. The solution: JapaneseModern is new OCR language available in the product. It does not include outdated Kanji. Our customers should use it to recognize modern documents with the best accuracy.
- Recognizing Katakana as Kanji (Hiragana) Character Issue (タ ->夕,オ->才,エ->工, etc.). ABBYY OCR mixes up similar characters where a human can easily identify correct ones. The solution: application of
- Context-based heuristics. It is something like ‘recognize “1-” instead of “ト” because a string looks like an address’.
- Japanese orthography rules. It is something like ‘do not put a Hiragana character in between two Katakana characters’.
- Missing characters issue. The solution: few frequent and missing modern Japanese characters were trained and added into the recognition set.
- Lack of Japanese text models issue. The solution: new models (helps with similar characters and mixed language recognition) are added:
- Date. Such as 2014年10月19日 (日).
- Address. Such as 東京都港区赤坂2丁目17−22.
- Dictionary issue. Existing dictionary contained ‘garbage’ and misses some initial forms. The solution: incorrect entries were removed, new initial forms are added (borrowed from UniDic dictionary popular in Japan).
FRE 11 R6 leverages differently on different test-beds: sometimes the improvements give nothing, sometimes the effect is very small (1% less errors), sometimes it is worth to mention (24.6% less errors).
Arabic Fathatan (ً) diacritics support
Arabic OCR got support for the Arabic Fathatan diacritics recognition. The initial request came from a ABBYY FlexiCapture 11 user. Since this improvement increases overall Arabic OCR accuracy, we decided to add this feature to FRE 11 R6.
Please notice that the improvement is valid for the last symbol in a word:
Thai OCR accuracy improvement
In a scope of entering into VIP account, we faced with low Thai OCR accuracy on several font types comparing to competitors.
The font types are following:
- Tahoma
- TH SarabunPSK
- TH Niramit AS
- TH Kodchasal
- TH Baijam
- TH Fah Kwang
Average accuracy was like this according to the customer’s report:
| Engine | Competitor A | Competitor B | ABBYY SDK |
| Average accuracy | 78.5% | 93.1% | 80.7% |
Dedicated support of colleagues from ABBYY Japan and R&D professionals’ efforts make it possible to overcome competition with the following result:
| Engine | Competitor A | Competitor B | OCRT 14 |
| Average accuracy | 78.5% | 93.1% | 91.3% |
The improvements in OCRT 14 were backported to OCRT 13 used in FRE 11 R6 release.
Internal test for FRE 11 R6 shows that it has 11%-13% better accuracy in Thai OCR on the test-bed containing 35 images of different document types.
Extended information on character position in a word
Previously the IsWordStart property tells if a character starts a word. For right-to-left writing, this parameter was ambiguous: logically a word starts from the right end whereas geometrically it starts form the left. To solve the ambiguity API and XML export got two new properties:
- IsWordLeftmost. Specifies whether the character is the leftmost character in a word.
- IsWordFirst. Specifies whether the character is the first character in a word.
The old property IsWordStart is declared deprecated and will be removed from API and XSD in FRE 12.
Smaller PDF with pages of mixed colority
Not all pages in a document are similar: one may contain color graphics; another may contain b/w text only. Here one can make PDF file smaller: compress color images with higher resolution and less compression, compress b/w image with lower resolution and higher compression. Frankly speaking you may notice that most of PDF creation tools allow you to set up individual resolution and compression for each type of pages: color, grayscale, and black and white.
In one of the previous FRE 11 releases, we added PDF exporting API for setting up individual compression for each page type described above.
Now we present additional API for setting up individual resolution:
- BwPictureResolutionParams
- ColorPictureResolutionParams
- GrayPictureFormats
In combination with existing API for compression selection PDF exporting API lets our customers to save PDF file size same way as other PDF creation tools do.
Please notice that new API does not work in MRC mode. From certain point of view, MRC and individual resolution/compression setting are two different approaches to the same goal: good look with low size. You cannot and should not mix them up; you have to choose one most appropriate for you.
Farsi OCR
From this release Farsi language is supported. It is added to the list of Predefined Languages. Win32 standard language identifier is equal to 1065.
The language is available, if Arabic module is included in license. Please note that as of now, dictionary support for this language is not available.
Internal accuracy measurement and competitive comparison look as follows:
| Test-bed | OCR Engine | Error level | |
| Characters | Words | ||
| Book | FRE 11 R6 | 9,9% | 12,1% |
| Verus 4.0 | 15,8% | 11,1% | |
| ReadIRIS 14 | 12,7% | 16,4% | |
| Doc | FRE 11 R6 | 8,2% | 8,5% |
| Verus 4.0 | 18,5% | 11,9% | |
| ReadIRIS 14 | 14,2% | 13,6% | |
| Wiki 1 | FRE 11 R6 | 11,8% | 10,9% |
| Verus 4.0 | 22,6% | 12,4% | |
| ReadIRIS 14 | 49,9% | 16,3% | |
| Wiki 2 | FRE 11 R6 | 21,9% | 14,3% |
| Verus 4.0 | 31,2% | 17,1% | |
| ReadIRIS 14 | 67,8% | 47,6% | |
| Wiki 3 | FRE 11 R6 | 13,3% | 10,6% |
| Verus 4.0 | 31,9% | 21,9% | |
| ReadIRIS 14 | 100,0% | 100,0% |
‘BarcodeRecognition_Accuracy’ became more accurate
The next technology cycle (14/15 version) includes a task for barcode finding improvements following a number of reclamations got from customers using ABBYY products based on 13th technology cycle and earlier. Recently R&D finished the task and back-ported results. That helped to close several high-priority reclamations and improve accuracy results on SDK test-beds like this:
- QRCode: 5.6% less errors
- EAN 13 with supplemental: 20.5% less errors
- EAN 13: 15.38% less errors
- UPC-E with supplemental: 10.5% less errors
- EAN 8 with supplemental: 5.9% less errors
That is in addition to fixed reclamations.
The accuracy improvement is included into ‘accuracy’ profile only because it brings also a slowdown. The slowdown varies from 5% to 70% depending on image complexity, detection type, and test-bed content (length and specifics).
Warnings are connected to particular pages
When processing a multi-page document one might get recognition warnings but was not able to identify a document page a warning belonged to. In case of homogenous page images along a document, this does not matter and makes not much sense. ‘Homogenous’ pages are common for single document scanned. As soon as somebody processes a file (set of different documents) or photos, the situation when a warning raises in the middle page becomes common and a page index starts to be very important.
To address the situation FRE 11 R6 presents updated IFRDocument::IFRDocumentEventsEx interface with extended OnWarning() callback returning PageIndex property.
FRE helps in ZuGFeRD scenario
The electronic invoices standard ZUGFeRD was accepted in Germany in 2014. This standard usage is meant to simplify the electronic invoices processing and to increase the efficiency of the work with e-document management.
A ZUGFeRD-compliant e-invoice must combine the human-readable representation and the structured data in XML format that can be recognized by computer.
The file format that satisfies these requirements is the PDF/A-3 format. It is a container for both the visual representation and the structured data in XML format.
ABBYY FineReader 11 Release 3 and later provides the special features for the files in ZUGFeRD standard processing.
To let our customers know FRE 11 is helpful in ZUGFeRD scenario we added the ‘ZUGFeRD-compliant electronic invoices’ article to the product documentation.
HTTP and SOCKs 4/5 proxy support for a license activation
It is common to use a proxy in a corporate network environment to protect it and manage an employee access to the Internet.
FRE needs to activate a license on a PC to work in case no dongle-based and no pre-activated license is used. If a PC is behind a proxy then FRE protection mechanism needs to know a login and a password for the proxy.
Starting from this release it is possible to specify a proxy type, a login, and a password for it in the ‘LicenseSettings.xml’ file.
Example:
|
<?xml version="1.0" encoding="utf-8"?> <LicensingSettings xmlns="http://www.abbyy.com/Protection/LicensingSettings"> <ProxyServer Type="SOCKS" Host="192.168.56.1" Port="9090" Login="user" Password="password" /> <LocalLicenseServer> <ConnectionProtocol ProtocolType="LocalInterprocessCommunication" /> <EnableIKeyLicenses Enable="no" /> </LocalLicenseServer> </LicensingSettings> |
Notice: the product documentation is missing the feature description. The fix is coming in R7.
Performance results
This section contains performance results of the release comparing to the previous releases. The processor of the testing machine is Intel® Core™ i5-3450 CPU (3.10GHz, 4 physical cores) with 8GB of RAM.
English
Japanese
Korean
Chinese PRC
Chinese Taiwan
Arabic
Fixed Bugs
No specific for Mac version bugs were registered and fixed.
Known Issues and Workarounds
Mac OS version limitations
The following functionality of FineReader Engine 11 for Windows is not available in the Mac OS version:
- DjVu opening
- Scanning
- ICR/OMR
- Visual Components and other GUI elements
- WDP/WIC/BITMAP input formats and other Windows-specific functionality
- PDF text layer reusing
- Attachments extraction from PDF
- Bookmarks extraction from PDF
- Metadata extraction from PDF (the information about author, keywords, subject and title)
Some API is not implemented
The following API is not implemented in FRE 10 and FRE 11:
- IFootnoteSeries::HasSeparator. Always returns “true”.
- ITextPicture::ColumnNumber. Always returns “0”.
- ICharParams::IsWordStart. Always returns “false”. It is true only for character parameters got through IWordRecognitionVariants interface.
- IIncut::TextWrapping. Always returns “TW_Undefined”.
- IRunningTitlesSeriesText::HasSeparator. Always returns “false”.
The implementation is not planned.
Farsi language is based on Arabic language
Farsi OCR output indicates Language ID as Arabic (CharParams::LanguageId = LI_ArabicSaudiArabia). This is because Farsi technology preview is based on Arabic OCR language.
The fix will be available in FRE 12.
IPDFMRCParams::MonochromeText doesn’t work correctly
Different algorithms of compressions during export to PDF are used with IPDFMRCParams::MonochromeText set to FALSE or DEFAULT whereas default value is FALSE.
Language auto detection uses CJK resources though none is selected for OCR
‘Cjk.*’ resource files are used while RecognizerParams::LanguageDetectionMode = TSPV_Yes even though recognition languages set does not include any of CJK languages.
The proxy feature description is missing in the documentation
The product documentation is missing a description for the feature ‘HTTP and SOCKS 4/5 proxy support for a license activation’.
The will be available in the FRE 11 R7.
30% slowdown in all scenarios
Internal tests shows that this release got 30% slowdown comparing to R2.
We are investigating the reason and working on a patch.
AddImageFileFromMemory does not open PDF files
An attempt to open a PDF file from a memory ends up with the error ‘The image file you specify is empty.’
R7 will include a fix.
PDF/A validation report
The following issues are detected by Adobe Acrobat 11.0.9 (Preflight 11.0.9) for PDF/A files produced by this release:
- In SourceContentReuseMode = CRM_ContentOnly the Engine sometimes (5% of the test base in Korean language) generates PDF/A-2a and PDF/A-3a files which Adobe Acrobat Preflight validates with the following message “Text is mapped to Unicode Private Use Area but no ActualText entry is present”.
- Sometimes PDF/A-1a/-2a/-3a files are not valid with the following diagnoses:
- “Character references .notdef glyph”
- “Glyphs missing in embedded font”.