We have a legacy application written by a developer which takes a PDF/text file and converts it to a TIFF. The user just prints the file to a custom print driver.Output of the driver is a Printer control language file and finally TIFF.
The user doesn't see the PCL file. PCL file is internally produced and inputed as a binary reader which gets converted to a TIFF.
How do I see the PCL File?? I would really like to have a small stand-alone test program which converts a PDF to PCl using this print driver and then TIFF.
The print driver is written in C, C++ code.
This driver was written in 2010. With the new Adobe version 2018.009.20050, text in adobe forms is not being captured.
I'd appreciate some pointers!
I do not have an answer but I wish to comment and follow the topic.
Like the poster, I'm working with a few virtual print drivers and have noted this change of behavior from Adobe Reader 2018.009.20050 is impacting them. Examples: Foxit's PDF Printer, as well as an HP PostScript Driver I've been using whenever I need to redirect a printstream to a file.
The issue seems to be that the new release of Adobe Reader is no longer recognizing these PostScript printers as such. A tell-tale sign is that Adobe Reader, when printing, has 'Advanced' options that would typically let someone designate some PostScript options/preferences. With the recent Reader release, these options are now disabled for all of my PostScript-capable printers, except when using the "Adobe PDF Printer".
My guess: like many Windows applications, when Adobe Reader prints to a device that it thinks is NOT PostScript-capable, Reader will choose to rasterize the PDF's text into image/vector data, rather than expressing it as text-and-font information. ( ..and some applications, like Chrome, seem to always do this, nevermind the type of printer. )
I am hoping that Adobe sees a bug here to be fixed soon. It's creating quite a headache otherwise.
In the meantime, I've found that Foxit's most-recent PDF Reader does NOT have this same issue. It continues to create PostScript for my set of virtual printers.
UPDATE (1/2/18):
This is Adobe's support article describing a different issue but the same proposed registry change for avoiding text rasterization.
Related
The problem is, we dont have MS Office in our university anymore, earlier we used its
preview feature in Windows File Explorer, so to view multiple assignments on the fly by
just clicking on the word file or using arrow keys navigation. This helped us the teachers, to
check many assignments without having to open each file 1 by 1. Now we switched to WPS Office,
thus the preview feature in windows explorer is gone. This made the assignments checking extremely
slow as now we have to open each file before marking it.
I am a teacher too, who can code a little, so I want to build up an application in windows forms,
that enables to preview .docx, .dox and .rtf files. I tried hard since 1.5 months so far, used
Pandoc, OpenXML Powertools, tried with trial versions of libraries like Aspire, Aspose, GemBox, Xceeds
But so far no free and reliable solution is found, some of them either spoil the formatting in unacceptable way. Some of them have trial limits. Most of them do not convert word own drawings (that the students draw inside Word document itself).
So basically I am looking for a reliable and free resource that converts the whole document,
doesn't miss anything and is free. We the teachers, still can overlook formatting a little.
What I have tried: Everything as listed above, in win forms application
Current best solution working for us: Using Syncfusion DocIO library to convert the said file
formats to PDF and then loading that PDF in a CefSharp browser control in winforms. This requires
just ~2 seconds load time of the document and gives nice zooming options. But its a trial version
and eventually it will expire after trial period.
NOTE: I cannot use any online or server based solution as it will be very slow (consider clicking on the file and then waiting for more than 10 seconds to load a converted document).
My bookdown report knitted to PDF tries to link to the underlying results like so
[This](./somedir/.) directory contains some data.
or so
[This file](./somedir/specific_data.txt) contains something more specific.
On (Arch)Linux using okular (my devel environment) all of this just works fine (file manager opens for the first, MIME type defined application for the second link), but on MS Windows and OSX Acrobat Reader asks whether to follow that link and after allowing to do so, the only thing that happens is that the dialog window disappears ...
Is what I want generally impossible on those platforms or am I doing something wrong?
Thanks, Joh
I found the solution:
[This](run:somedirrelativetothedocument/.) directory contains some data.
[This file](run:somedirrelativetothedocument/specific_data.txt) contains something more specific.
I can insert MS Word files as OLE into a DOORS object, both manually and via DXL, but PDFs (and EPS as well) behave different: it is difficult to make those not appear as icon.
I able to insert a PDF file (showing some graphics) as OLE manually only by using the dialogue's Create New radio button with specifying the type explicitly as Adobe Acrobat Document (without the Display As Icon option). All is well in this case.
Using the radio button Create from File button leads to the same undesired behaviour as using the DXL function insertOle() to insert the object: the result is displayed as icon only.
if (oleInsert(current, "c:\\temp\\27.pdf", false))
print "Successfully embedded document\n"
else
print "Problem trying to embed document\n"
Gives me:
Double-clicking the icon opens the associated application (Acrobat Reader) and shows the embedded PDF properly. However, the OLE properties dialogue displays the type Package. Manual insertion as described above creates an OLE object with the type Adobe Acrobat Document (as specified while creating it).
Inserting a Word document via DXL instead of the PDF makes the embedded document being rendered properly -- apparently the type is determined automatically and correctly:
Apparently, I am not able to (but would have to) specify the OLE type when inserting the PDF.
I am aware of a similar problem at the IBM forum, but the code from there did not even update existing OLE objects but left my objects without any OLE content! Another thread addresses that problem too, but does not provide a detailed solution.
There are two things I would check that would cause a different result for you and your colleague:
Check if they have a full 'edit' version of Adobe Acrobat installed. Since OLE is a Microsoft standard, having Full Acrobat instead of just the Viewer installed may register components with Windows that allow the OLE to display properly for them.
If they do not have Full Acrobat installed, then perhaps they have a different version of the Viewer or a 3rd party PDF viewer that you do not have on your machine.
The DXL reference manual specifically states that An OLE package is created if a file has no associated applications that support OLE. So your system is not recognizing the association, but your colleague's is.
The root cause is still unknown, but the problem was solved eventually. My Windows user account was deleted and created from the scratch. Now it works.
Another colleague has the same problem -- maybe we will take the time and try to isolate file / setting which contained the cause.
here is a different type of requirement in my project regarding pdf.
I want to generate a pdf with few of prefilled values. rest of the fields can be filled by user so Pdf should allow the user to edit the pdf so that he can save it locally on his system.
The pdf may contain checkboxes and textboxes.
I have worked with "itextsharp", "abc pdf" and "Rad Pdf".
For this purpose i can't use "Rad Pdf", due to some limitations by project owner.
Please share your valuable answers to give me a proper way to do this task.
Looking forward for your replies.
You need to use Adobe Professional, you can turn your existing electronic or paper forms into fillable forms with a few clicks.
http://adobe.ly/Ydc7qb
Acrobat Reader XI provides features to save eForms out of the box.
Provided your clients are using this version of Acrobat they will be able to fill in and save standard PDF forms.
The only problem you may have relates to older versions of Acrobat Reader which did not have this feature.
So any eForm produced using ABCpdf or indeed any PDF library should work the way you want provided your clients have a recent version of Acrobat Reader.
ABCpdf includes an example project called 'Annotations' which shows how to create eForms in this way.
My replies may feature concepts based around ABCpdf .NET because it's something I work on. :-)
When developing a WebOS application with Enyo, is it possible to access the clipboard contents? That is, if I copy a bit of text to the clipboard on a Touchpad or Pre device , can I programmatically grab that piece of text, or programmatically replace it?
From what I've read in the SDK documents, I assume I'd need a Service to do this. Is this correct?
If so, which service? Are there a list of services available, and/or is there a way to reflect into the framework to see which services are available?
(New to WebOS development, so error on the side of speaking loudly and slowly)
I think you are looking for the getClipboard method on the enyo.dom. However, when I try:
enyo.dom.getClipboard(enyo.bind(this, "gotClipboard"));
gotClipboard: function() {
this.log(JSON.stringify(arguments));
}
I just get {"0",""}, even though I have text in the clipboard. It makes me wonder if this isn't fully baked yet. One argument will be the text in the clipboard when it works.
If I try the companion enyo.dom.setClipboard, I get a NOT_FOUND_ERR: DOM Exception 8.
Found both of these functions in here: https://developer.palm.com/content/api/reference/enyo/enyo-api-reference.html