Accueil → WINDEV 24 → Euro sign and PDF
Euro sign and PDF
Débuté par Arie Mars, 27 juil. 2011 19:20 - 11 réponses
Posté le 27 juillet 2011 - 19:20
From my application one can make invoices. Of course there is field for the total amount to pay, like ¤ 123,45
Then preview on screen is correct. Printing to paper is correct.
But when generating a PDF, the euro-sign moves several pixels to the right. And is placed right in front of the first digit or even on top of it
like ¤123,45 or even worse.
I tried to add some extra spaces in between, but this doesn't help for some reason.
Anyone seen this before?
Posté le 28 juillet 2011 - 11:13
You are generating the pdf from print preview windows or printing directly to a pdf file?
I can't find out why but in some situations the pdf generated from the print preview windows have some strange behaviour, in this cases i print directly to the pdf file and if i want to show it to the user i open it by code.
Posté le 28 juillet 2011 - 11:13
Did you try with the ¤ on the right side?
Posté le 28 juillet 2011 - 11:13
that doesn't make any difference.
Also the generic-pdf-option doesn't help.
It only happens btw, when the euro is included in the currency-mask.
I can overcome this by adding a seperate field for the euro on the report. And remove the euro from the mask. But then I have to change quite a number of reports.
Posté le 28 juillet 2011 - 11:13
Did not, because this particular customer of mine doesn't want that :(
Posté le 28 juillet 2011 - 11:13
bad luck.:sneg:
Posté le 28 juillet 2011 - 11:14
Hi Arie,
I had similar issues where PDF output differs from printed output.
An item that was completely visible in the printed and preview version had overflow in the pdf. One of those 10 times slower issues!
I had to make the item wider and check the pdf :-(
Just found out that a pdf background for a report does not display properly (logo becomes square instead of round) Another workaround to be found. :rolleyes:
Did you try the pdf generic option, where the printer driver is not used?
Posté le 28 juillet 2011 - 12:10
Hi Piet, the generic option did not help :(
Posté le 28 juillet 2011 - 17:23
Hello Paulo
I have to develop a acces control application using SUPREMA using Windev, and the examples that comes with the device is written in VB language.
Please can you help me, or can you send me some exemples written in Windev.
Thank you.

Posté le 28 juillet 2011 - 18:23
Hi Arie,
I've seen similar problems with some other applications. The euro sign combined with the numerical value is problematic. Maybe because of one of the basic "crimes" against the basic data processing rules: The data must be divided into as small pieces as possible, and not any smaller:-)
I have found only two solutions:
1) use the international currency code "EUR" (or whatever currency the user is using, preferably read this from a parameter file...)
2) use an image of the Euro-sign (if the currency is EUR, or whatever sign, according to the currency used).
best regards
Posté le 28 avril 2020 - 19:27
Me toca hacer lo mismo, que recomendacion me das??
Membre enregistré
19 messages
Posté le 30 juin 2020 - 11:50
Hi Arie,

I guess this is a ticket for PCS Support as it is likely to be related to the rendering of that mask into the PDF format. Potentially it could also be a TT font issue that needs to be embedded in the PDF or that needs to be on the system.

On the other hand, I think this is potentially bad design for any system as it renders the application useless in a multi-currency environment. There may be a good reason of course as it may be a purely small local use application without any ambition whatsoever to internationalise your solution one day (or a country stepping out of the Euro-zone on another day, or a Euro-company that needs to send out e.g. USD invoices to a customer in Asia, etc...).

Typically and in about any data processing system I designed and worked with, the currency code is a separate field in the tables and I never use 'automatic currency masks' like the ones offered by PCSoft. This means that in reports you would be printing it as two fields which would also solve the display issue. There's other complexity surfacing in this case as well of course...

Just my 2 cents !

Peter Holemans