I have been evaluating your Mini EMF Print driver to write serialized
TIF files and call our post processing routine. Integration looks
promising but there is one feature that seems to be missing that we
would need (and would be willing to pay for).
We want the ability to perform a targeted text extraction, not of the
entire print job, but just the text discovered between a range of
arbitrary but well chosen delimiters that don't normally appear in
text strings. Is it possible for any of your print driver products to do this?
For example, this email contains some text, but we would want only the
following extracted and returned to us:
Filing Info: ~@? This is the info to extract ?@~
And if possible we would want the delimited text to not appear in the
image file that is created.
============================================================
Thanks for your message, do you want delete some text strings from generated EMF files?
VeryPDF
============================================================
Thanks for your reply.
To clarify, we are using the Mini EMF Printer driver to generate serialized TIF images. See the attached zip file for the config file that is being used with the driver.
We are not sure if EMF files are generated by the OS and then you use them in transition to making the TIF file output, but we are not interested in EMF as the final output. The driver already generates the image files we desire as is.
If your driver is indeed taking the EMF file and converting it to TIF, then the additional functionality we are seeking is to have your driver filter out a particular kind of EMR_EXTTEXTOUTW record by examining its EMRText object for a specific sequence of characters. (1) We want your driver to extract the qualifying text object data and return it to us, ideally as a passed parameter #2 in the RunExe process (see the config file for that too.) and optionally (2) either delete or ignore the EMF record prior to creating the TIF file or change the EMRText object to 0 length.
I have attached a zip file that contains the option.ini file we are using with the driver, a sample text source we are printing to the driver using notepad, the resulting TIF image you are already generating, the corresponding EMF file if the option.ini is changed to output that instead, and a screenshot from our EMF Explorer tool showing the record type we would like extracted and returned and then either deleted/ignored/truncated.
Since we don't know how your software actually generates the TIF files, we do not know what interim steps or formats are being used in the print process.
I hope that explains things more clearly.
============================================================
Thanks for your message, we can provide this custom-build version of Mini EMF Printer to you, this custom-build version will support following new functions,
1. Output text contents to a text file, (we don't retain original layout in this text file, it is just a plain text file)
2. we will delete EMR_EXTTEXTOUTW record before render EMF to TIFF image,
Is this okay to you?
VeryPDF
============================================================
I want to clarify from your last email, we only want the text from the specific EMR_EXTTEXTOUTW record delivered in text form, not all of the text from the print job.
I could also use more documentation on the various options in the options.ini file, especially how to use the RunExe parameter with an external program and what parameters are available to be passed.
============================================================
Thanks for your message, OK, we will extract the text from EMR_EXTTEXTOUTW record only.
Please by following steps test "RunExe" in option.ini file,
1. Please use MS VC++ application to compile attached "runexe.cpp" file into "runexe.exe" application,
2. Please copy this "runexe.exe" application to C:\ folder,
3. Please open "option.ini" file, set the value of "PATH=" to "C:\runexe.exe" application,
For example,
~~~~~~~~~~~~~~~~~
[RunExe]
PATH=C:\runexe.exe
~~~~~~~~~~~~~~~~~
4. Please print a document to Mini EMF Printer, C:\runexe.exe will be called by Mini EMF Printer automatically,
5. You can modify "runexe.cpp" file to best meet your requirement, you can do anything in this "runexe.cpp" file,
We hoping above steps will helpful for you, please to try.
VeryPDF
============================================================
We have finished this EMF2Text application to you, please download it from following URL,
XXXXXXXXXXXXXXX
after you download it and unzip it to a folder, please run "test.bat" file, you will get a new text file and an EMF file, EMF file doesn't contain EMR_EXTTEXTOUTW record.
Emf2text application support following options,
~~~~~~~~~~~~~~
Usage: emf2text [options]<emf-file> [<out-file>]
-newemf<string>: Create a new EMF file without EMR_EXTTEXTOUTW record
Example:
emf2text.exe C:\in.emf C:\out.txt
emf2text.exe -newemf C:\out.emf C:\in.emf C:\out.txt
~~~~~~~~~~~~~~
You can use -newemf parameter to create a new EMF file which not contain EMR_EXTTEXTOUTW record, emf2text will output text contents to a text file, this text file contains following information,
~~~~~~~~~~~~~~~~
[ 100,1256, 440,1323] 'Wednesday,'
[ 441,1256, 998,1323] ' December 15, 2010'
[ 999,1256,1015,1323] ' '
[1320,1168,1336,1180] ' '
[2297,1234,2313,1247] ' '
[1897,1241,2193,1311] 'New York,'
[2195,1241,2296,1311] ' NY'
[2484,1242,2576,1309] '27°'
~~~~~~~~~~~~~~~~
The format is:
[left, top, right, bottom] 'Text Contents'
You can read every line into your application easily.
You can integrate emf2text.exe into your application by yourself, however, if you wish integrate this emf2text.exe into Mini EMF Printer, please feel free to let us know, we will integrate it into mini EMF Printer and provide a new version of mini EMF Printer to you shortly.
VeryPDF
============================================================
I have downloaded and tested the code you provided. It is not quite what
was specified in my 8/21 and 12/10 emails (in this thread, for reference).
To review, I want only the EMR_EXTTEXTOUTW records that match a specific
start character sequence (in my email I referenced ~@? as the 3
character sequence) extracted and then deleted.
All other EMR_EXTTEXTOUTW records that do not begin with the above
sequence of characters should be left alone.
The application you provided does not perform the filtering as was
specified, so that needs to be changed.
In answer to your 2nd question, yes I want the output to consist of a
set of serialized TIFF files and a text file that contains the text from
any extracted and deleted records. My preference is to have this
integrated into
Mini EMF Printer by you. I don't really need EMF output and would prefer
to have Mini EMF Printer generated the TIFF images directly.
However, it is important that the TIFF images be generated only after
any EMR_EXTTEXTOUTW records have been removed from the spool file first,
so if that means Mini EMF has to generate an EMF output file that is
then processed into TIFF that is fine. Please integrate into Mini EMF
driver.
Please let me know if you have any questions and especially if you are
still unsure exactly what I am expecting as the final output of the
printing process.
============================================================
OK, we have fixed this problem, in the new version of emf2text.exe application, you can specify this keyword by -begintext parameter, for example,
emf2text.exe -begintext "~@?" -newemf C:\out.emf C:\in.emf C:\out.txt
Thanks for your message, we understand your meaning now, please download a new version of mini EMF Printer from following URL,
XXXXXXXXXXXXXXXXXXX
This package contains new version of emfcreator.exe, emf2text.exe and option.ini files, if you wish create the TIFF file and remove text contents which begin with "~@?", you can set following options into option.ini files,
~~~~~~~~~~~~~~
[AutoSave]
OutputFile=C:\out.tif
IsAutoSave=1
[RunExeOnEMF]
PATH=emf2text.exe -debug -begintext "~@?" "%1"
~~~~~~~~~~~~~~
"OutputFile" will output TIFF files to C:\ folder, of course, you can set "OutputFile" to D:\out.tif or D:\test\test.tif or any other filename that you want.
"RunExeOnEMF" option will set the parameters to emf2text.exe application, if you use "-debug" parameter, emf2text.exe will backup EMF file for debug purpose, of course, you can remove "-debug" parameter from option.ini file.
There has two issues I have to explain,
Issue 1:
-begintext parameter will set "~@?" keyword to emf2text.exe application, emf2text.exe will remove following text lines from EMF files,
~@?abc
~@?123456
~@?test
However, it can't remove following text lines,
~@abc
~abc
~@test
Because above text lines are not begin with "~@?", this is what you want it?
Issue 2:
emf2text.exe application will output found text lines to a text file which filename same as original EMF file, this text file contains rectangle position for text lines, this rectangle position is match to EMF file, but not output TIFF file, is this rectangle position okay to you?
~~~~~~~~~~~~~~~~
[ 100,1256, 440,1323] '~@?Wednesday,'
[ 441,1256, 998,1323] '~@?December 15, 2010'
[1897,1241,2193,1311] '~@?New York,'
[2195,1241,2296,1311] '~@?NY'
[2484,1242,2576,1309] '~@?27°'
~~~~~~~~~~~~~~~~
VeryPDF
============================================================
I have tried the new code on a couple of test machines running Windows 7 x64. I am having the following problems:
1. When printing from an x64 application like notepad or IE, the job spools and I get the emf debugging created, the tif file created and the extracted text file created. However, the tif file is incorrectly formed and missing many text and graphics objects. If I comment out the reference to emf2text in option.ini then the tif file is generated correctly. You can reproduce this behavior clearly by just sending a Windows Test Page to the Printer.
Summary: debugging EMF file=correct, text extraction=correct, tif=failed if emf2text is used.
2. When printing from an x32 application like firefox, print job goes into the spooler and sits there indefinitely with a status of "Printed". Event viewer logs the following error:
Log Name: Microsoft-Windows-PrintService/Admin
Source: Microsoft-Windows-PrintService
Date: 12/23/2010 4:22:20 PM
Event ID: 372
Task Category: Printing a document
Level: Error
Keywords: Classic Spooler Event,Document Print Job
User: XXXXXXXXXX
Computer: XXXXXXXXXX
Description:
The document Yahoo!, owned by XXXX, failed to print on printer VeryPDF Demo EMF Printer. Try to print the document again, or restart the print spooler.
Data type: NT EMF 1.008. Size of the spool file in bytes: 26398764. Number of bytes printed: 26398680. Total number of pages in the document: 1. Number of pages printed: 1. Client computer: \\W764. Win32 error code returned by the print processor: 5. Access is denied.
As you might imagine, since the spooled EMF file is not processed no output files are generated and no processing takes place.
Printing to other physical and virtual printers work okay (such as Microsoft XPS) from both x32 and x64 applications, so it seems to be related to just the VeryPDF EMF Printer itself.
3. When printing works (as with x64 applications) I don't understand how I am supposed to match the resulting output file with the corresponding extracted text file name. They appear to be completely unrelated. I understand that %1 in option.ini RunExe represents the link to the outfiles.txt that contain the list of generated tif files, but nowhere is there instructions on how to determine the corresponding text extraction file name. Could you provide that perhaps as %2 in the option.ini? Or include the text file path/name in the outfiles.txt file that I parse?
4. The code you provided installs a Demo Version of the print driver. Did I miss a step when deploying the driver or do you expect that I should be purchasing a developer license in addition to the fees already paid to you for the custom driver?
5. In response to your questions from the last email message. Issue 1 is understood, the string extraction is performing as expected (in my limited testing due to all the other issues). Issue 2 is okay. The rectangle coordinates of the extracted text are ignored by our application.
============================================================
We have created a new version to you, please download the new version from following URL to try again,
XXXXXXXXXXXXXXXXXXX
When printing from an x64 application like notepad or IE, the job spools and I get the emf debugging created, the tif file created and the extracted text file created. However, the tif file is incorrectly formed and missing many text and graphics objects. If I comment out the reference to emf2text in option.ini then the tif file is generated correctly. You can reproduce this behavior clearly by just sending a Windows Test Page to the Printer.
Summary: debugging EMF file=correct, text extraction=correct, tif=failed if emf2text is used.
We have improved this function in the new version, please test the new version again, please feel free to let us know if you still have same problem.
2. When printing from an x32 application like firefox, print job goes into the spooler and sits there indefinitely with a status of "Printed". Event viewer logs the following error:
The document Yahoo!, owned by XXXX, failed to print on printer VeryPDF Demo EMF Printer. Try to print the document again, or restart the print spooler.
Data type: NT EMF 1.008. Size of the spool file in bytes: 26398764. Number of bytes printed: 26398680. Total number of pages in the document: 1. Number of pages printed: 1. Client computer: \\W764. Win32 error code returned by the print processor: 5. Access is denied.
As you might imagine, since the spooled EMF file is not processed no output files are generated and no processing takes place.
Printing to other physical and virtual printers work okay (such as Microsoft XPS) from both x32 and x64 applications, so it seems to be related to just the VeryPDF EMF Printer itself.
We have fixed this problem in the latest version of mini EMF Printer, please test the new version.
3. When printing works (as with x64 applications) I don't understand how I am supposed to match the resulting output file with the corresponding extracted text file name. They appear to be completely unrelated. I understand that %1 in option.ini RunExe represents the link to the outfiles.txt that contain the list of generated tif files, but nowhere is there instructions on how to determine the corresponding text extraction file name. Could you provide that perhaps as %2 in the option.ini? Or include the text file path/name in the outfiles.txt file that I parse?
We have update the emf2text.exe file in the new test package, the new version of emf2text.exe does support -textlist parameter, you can use this parameter to specify a file name, emf2text.exe will write all filename of text files to this text file, you can read all filename from this text file at later, for example,
[RunExeOnEMF]
PATH=emf2text.exe -debug -textlist textfiles.txt -begintext "~@?" "%1"
4. The code you provided installs a Demo Version of the print driver. Did I miss a step
when deploying the driver or do you expect that I should be purchasing a developer
license in addition to the fees already paid to you for the custom driver?
You needn’t purchase mini EMF Printer respectively, we have set your license key in the option.ini file, you can use new version without any restriction now.
5. In response to your questions from the last email message. Issue 1 is understood, the
string extraction is performing as expected (in my limited testing due to all the other issues).
Issue 2 is okay. The rectangle coordinates of the extracted text are ignored by our application.
Thanks for your message, please test the new version carefully, if you encounter any problem with new version, please feel free to let us know.
VeryPDF
============================================================
Wow, that was a fast response. Thank you!
All of the concerns raised in the prior emails have been addressed. I will begin more advanced testing next week, but for now I have just a few operational questions:
1. The output files tif/jpg format etc, are being written without any resolution tag. While minor, this will cause problems with certain image viewers (especially during printing) when the user has the "scale to dpi" option chosen.
2. I see how to control the image parameters using option.ini. Is there a way for the user to have control of resolution and / or color depth from the printer object property pages at print time as well? The printer object property pages are not tracking the option.ini settings and don't appear to have any influence on the output.
3. Since option.ini controls file naming and outputs static named outfiles.txt /textfiles.txt, can it be assumed that processing of multiple spool jobs in the queue will occur synchronously and that the next spool job will not be run until our RunExe process has completed and terminated?
Thank you for all of your hard work.
============================================================
We have solved this problem in the new version of emfcreator.exe application, please download the new version from following URL to try again,
This function can't be done easily, so the current version of mini EMF Printer doesn't support this function, sorry for this matter.
Yes, you can print more jobs to mini EMF Printer at same time, mini EMF Printer will control the "queue" and process every print job automatically.
VeryPDF
============================================================
We have just begun distributing our application beyond the beta
environment and have hit a snag. On a Windows 2008 R2 x64 system logged
in as an administrator (domain admin) we are able to run setup64 and the
printer gets installed properly in Devices and Printers. However, when
we try to print a test page (or anything else), the job spools and then
sits in the queue with a final status of "Printed" but no output file is
created and our application handler is never executed.
I have confirmed that swaprun.exe is being executed but do not have
expertise to troubleshoot this further. Can you provide some guidance on
where to look to troubleshoot this problem?
============================================================
Before going further, we setup test server and work to duplicate problem with MiniEMF Driver. It looks now like it is a bug or perhaps a product incompatibility with Terminal Server Mode and EMFCREATOR.EXE.
The problem affects uncustomized EMFCREATOR.EXE as well as custom EMFCREATOR.EXE that was built for us in December. It also looks like it should affect all versions of Terminal Server too, and your other customers.
Nature of the Problem: When the print driver is operated on a terminal server that has terminal services role installed and operational (terminal services user mode, not application setup or administration mode), EMFCREATOR attempts to locate the spool files in the private user directory %UserProfile%\Windows\System32\Spool\Printers instead of the standard spool file location.
A trace of EMFCREATOR indicates that you are using WinAPI call GetWindowsDirectory to determine the base path for the spool files location, but that API call undergoes a behavior change when run under Terminal Server (all versions) which is why EMFCREATOR fails. From MSDN on GetWindowsDirectory:
If the application is running in a Terminal Services environment, each user has a private Windows directory. There is also a shared Windows directory for the system. If the application is Terminal-Services-aware (has the IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag set in the image header), this function returns the path of the system Windows directory, just as the GetSystemWindowsDirectory function does. Otherwise, it retrieves the path of the private Windows directory for the user.
From TS CMD prompt, you can use "CHANGE USER /INSTALL" and "CHANGE USER /EXECUTE" to switch between the modes.
Solution might be to use API call GetSystemWindowsDirectory as stated above, or to mark the executable header with the TSAWARE flag (see your VC++ docs for the correct compile switch).
Let me know if you want to see any logs, like emfcreator.log or if you want remote access into our sandboxed Server 2008R2 test server.
============================================================
Thanks for your information, we will research this problem shortly, we will let you know after we have any finding on this problem, thanks for your patience.
VeryPDF
============================================================