Beiträge von winpple

I found a very simple way to solve the above needs and it works well, and does not require any special support of any kind in the libraries or capturing EMF output from the spooler.

I just do the printing twice at the same time. When the application opens a printer, I silently also start a PDF. I re-use the device metrics of the printer device context to setup my pdf environment, so that all code calculating positions and sizes gives results valid for both print supports.

When a new page start, I have a win32 StartPage and a wpdfStartPage, and so on... Every TextOut, and other calls are simply doubled, on the printer DC and on the pdf DC. Fonts can be shared (selected both in the print DC and in the pdf DC at the same time), as well as some other resources. This is very convenient as I already had some generic methods encapsulating the gdi primitives. Of course, I play with paper bins/trays as requested by the app on the real print and simply ignores these for the pdf side. When I'm done closing the print job, I'm done closing the pdf file and that PDF file is inherently built as a visual clone of the direct printout. This is exactly what I was looking for in this forum thread and it is really simple.

This is actually a superb demonstration of how nicely the pdfControl acts as a gdi device context and how easy it is to migrate a common gdi printing source code to one doing pdf output.

I will now cleanup all these experiments and within some days I will order the needed commercial licenses.

Or maybe really inject some comments records/tags in the PDF with the printer bin selection (which would be ignored and invisible when displayed printed) but could be interpreted while printing the PDF. That would imply collaboration from both pdfControl (to let insert such arbitrary 'comments' before some pages ion the PDF) and pdfView (so that printing can optionally interpret those comments as printer bin assignments).

My goal is not to be able to print the PDF file *later* and still follow the bins assignments. No, I just need to follow the bins assignments when the PDF is printed the first time when it is created.

Could I somehow setup my windows printing task such as to intercept it in EMF, get pdfControl or rtftopdf to convert the EMF to PDF, and then let windows continue on and print the EMF itself ?

Maybe with such an organization I could still use printer bins (I guess those calls setting up the bins end up in some form in the EMF) and yet capture a PDF copy (I can loose bins assignments by then) of each of my prints without duplicating the effort ?

I am considering pdfControl for licensing but I' ready to upgrade my goals to rtf2pdf if it helps fits that scheme.

Any ideas ? (I apologize as these posts are not really product support oriented but go a little bit beyond).

Zitat von wpsupport

Hi,

I am working on a solution. There is a problem with VS2005 which was not there before. VS2008 should work alright.

Julian

By the time I had that problem in may/june, it was with VS2008. Since then I tested (today) the latest download for the demo and it now seems fixed. That's why I went back on the work of evaluating the product more completely. Thanks for the fix you did in between!!

Does someone knows if there are *any* provisions in the PDF specification to insert printer bin selection codes or hints? Such instructions would only be significant for the exact printer it was designed for and probably ignored as invalid (silently) in most cases ?

The goal is this: find a way to design the printer output of a software such that it is 100% PDF based (always printing to PDF) even though sometimes the user prints "directly" to the printer. In such case the PDF would be produced and stored ("behind the curtain") and printed immediately. It offers a very nice and easy way to archive each and every printout done (for some days or weeks). The one thing which seems without solution is that the software need to address multiple bins : for the first copy of the multi-page invoice, send page one to this bin A, send page 2 and others to that bin B. And for all other copies of that same document, send for instance all pages to bin C.

These two requirements (wanting a PDF based solution and support for printer bins) seems contradictory and without solution. Is there some idea here?

Another idea I have would be to structure the output such that each page is generated independently of others and each i printed immediately after buying finalized, to the right printer bin. The collection of individual pages can then be automatically be appended to save a single PDF file of the document even though the individuals pages where printed to various bins and papers.

But this might pose some performance issues. Or PDF size issues. I am not sure it is worth some coding to test it. Any suggestion ?

Zitat von wpsupport

Hi,

If you have a PDF which uses this style it would help. Unfortunately the windows hash stzles depend on device resolution - something which is not possible to duplicate straight forward inn PDF which uses logical distances. THe conversion back to windows is something which would require line drawing in own code, avoiding windows GDI.

Julian

Here is a good one to test:
http://libharu.org/demo/line_demo.pdf
The dotted lines are not the only issue. But I do not heavily depend on the other details.

What your explaining above is that WPViewPDF does translate the postscript instructions of the pdf file to Windows GDI instructions, instead of actually rendering by itself a device resolution dependent bitmap then displayed ? That sounds as a really good idea, and yes I can understand it then pose some limitations. Yet you might want to translate dotted and hash lines from the pdf to small straight line segments made through the GDI. Just an idea and I'm not sure it can apply.

Yours,

Zitat von wpsupport

I just uploaded the release V2.23.1

It improves the rendering, the method pdfMakeJPEG and centers the pages horizontally in the window.

Thank you for this new version with some fixes and some enhancements. Yet, I have a *BIG* wish. What should I do to be informed of new versions in a more automated way ? Is there a mailing list I could be part of to get these announces ?

Zitat von winpple

I'm asking for events (one per each page sent to the print job) while printing between the open and close of the printer device. ... Thanks for considering it for a later version.

I have installed and tested (a bit) the latest version (2.23.1.0) and I have discovered the new events for start, page and end of print. I have implemented my progress bar using these, and it looks it works perfect. Thanks for this enhancement.

If I produce a landscape PDF, one where the page size is 297mm horizontal by 210mm vertical, the pages of that PDF look okay in the viewer on the screen. Though when printed using the component PrintDialog method, the printout is wrong. It looks like in landscape orientation but prints scaled down such as it is not wider than a portrait printout (so it uses 210 mm of width on the 297 mm horizontal direction and only 148 mm height on the 210 mm vertical direction). Hard to describe it better with words. If you want a sample by email, I have got tons.

Zitat von winpple

Ok, this is exactly the problem.
Do you intend to fix this anytime?

I have tested it with the latest version as of June 12 2008, it looks like this is not yet implemented. If at least it could print a solid line of the right thickness it would help. The issue today is that it not only ignores the dot and dashes and goes solid but apparently ignores the line thickness and prints a thicker line than expected.

Zitat

A progress bare is not possible though since you cannot know on which page the printer spooler is working. The printing itself is usually faster than the spooling time.

Sure. I'm asking for events (one per each page sent to the print job) while printing between the open and close of the printer device. What happens afterwards (windows actually printing), I don't care. I only care of the portion of time when the component is busy sending pages to the spooler, because during that time, without some visual feedback, its mostly dead to the end-user. We're talking printing PDF files of tens or hundreds of pages. it can take some significant seconds to send 100 pages to the spool job.
I think we understood each other on this topic.
Thanks for considering it for a later version.

Works like a charm. I should not have read an 'H' for a '#'. There is no issue with the software, only with my eyes. ;-)

Hello,

How to enter the license name, key and number correctly using the naked DLL? (That is having done CreateWindow on the right class and sending messages to the window) ?

Should this be valid ?
const char* lickey= "....";
unsigned liccode = ....;
SendMessage(WM_USER+77, 290, (LPARAM)lickey);
SendMessage(WM_USER+79, 1290, liccode);

Or is using the strange 'TWPComRecStruct' I see in the csharp interface along with SendMessage(WM_USER+85, ...) the only way to succeed ?

I really would *love* if the viewer window sends some WM_PDF_EVENT (events IDs to your liking) so that it reports progress during the print process. When I view a 10 pages document and prints it like this:

SendMessage(WM_USER+79, 155, 1); // COMMAND, ShrinkIfRequired
SendMessage(WM_USER+79, 32, 0); // COMMAND, PrintDialog

I have no opportunity to display any progress window. That would not be luxury to be able to do it. Now think about it with a 100 pages report. Along the same lines, some way to cancel the print in progress wouldn't be luxury too. But it comes one priority level below, I think.

Note that I wouldn't mind if you prefer to handle the progress window from within the component. The goal is to have one, so that users are not left in the dark.

Now the stupid question: is this already there and did I miss something obvious?

Zitat

Is this supplemental DLL still needed to display PDF files using truetype fonts ?

Answering to myself: only if using embedded truetype fonts.

Dear Julian,

Excuse-me but in-between I had uninstalled that demo to better concentrate first on my viewer needs. For building my PDFs I use another library which is mostly satisfying. I will come back to better test PDFControl when I'll have more time available.

Olivier.

Zitat

Currently the pattern which is selected by the post script command [...] d cannot be displayed. s olid line will be drawn.

Ok, this is exactly the problem.
Do you intend to fix this anytime? I routinely have to produce outputs similar to official forms like custom or taxes forms and those people seem to love to use dotted or hashes to divide some areas in multiple cells. To get such layouts to be conformant they must at least be printed correctly. This is why this detail is important to me, else I would not even have bothered anybody with it.

By the way, thank you very much for your pre-sale support !

This is the last detail that keeps me from selecting this product. ;-)

I have PDF files using dotted and hashes for line style which look weird in wpViewPDF and fine in other viewers. Dotted or dashed lines look thicker and continuous. They are fine in Adobe Reader (Windows) and Apple Preview (Mac). So I guess it is a rendering issue and not a production issue.
Can you confirm this ?
Is a fix possible ?
Do you need samples to reproduce ?
(It really should'nt be difficult to reproduce).

So it may be better for me not to use type 1 fonts. What about TTF ? Is this supplemental DLL still needed to display PDF files using truetype fonts ?