Hello Paulo, Coming back for the WMF integration issue ...
Guillaume, my colleague has contacted Microsoft about this, ant it appears that we didn't use the correct mode in our generation of WMF file. Find below the threads concerning this problem : What do you think about that ? Can this helps ? Thanks. Valerie -------------------------------------------------------------------------------- De : Peter Wheat [mailto:[EMAIL PROTECTED] Envoyé : lundi 12 novembre 2007 10:57 À : Guillaume Chassigneux Cc : 'THOLLOT Samuel' Objet : RE: SRQ071106600648 Hi All, This reply may be due to the fact that earlier you were using MM_ISOTROPIC. See: http://wvware.sourceforge.net/caolan/mapmode.html Now you are using MM_ANISOTROPIC means that parameters passed to SetViewportExt and SetWindowExt are taken literally. Windows makes no adjustment. They should be able to map the co-ordinates passed in the WMF records to the PDF co-ordinate system. Ask them why they cant? Also I note from the links below that they have added a parameter to adjust font spacing. Can you use this to work around the problem? Kind regards, Pete. From: Guillaume Chassigneux [mailto:[EMAIL PROTECTED] Sent: 12 November 2007 09:31 To: Peter Wheat Cc: 'THOLLOT Samuel' Subject: RE: SRQ071106600648 Hi Peter, You are right when you say the problem comes from the WMF insertion in iTextSharp document. We have already contacted iTextSharp support about this and they answered us that only Microsoft can render correctly the font width. I don't know why and how but here are the threads about this : http://www.mail-archive.com/[email protected]/msg33524.html http://www.mail-archive.com/[email protected]/msg33604.html http://www.mail-archive.com/[email protected]/msg33608.html quote : "The problem is that it's impossible to render fonts with the correct width in wmf. Only Microsoft knows what the "correct" width is." What do you think about that ? Guillaume -------------------------------------------------------------------------------- De : Peter Wheat [mailto:[EMAIL PROTECTED] Envoyé : lundi 12 novembre 2007 09:56 À : Guillaume Chassigneux Cc : 'THOLLOT Samuel' Objet : RE: SRQ071106600648 Hi Guillaume, As you say, the wmf and emf are fine. The errant behaviour is seen only in the pdf. The problem seems evident for italic and bold text. You need to look at the iText source to see why this Is happening, and modify / rebuild the iTextSharp component. See: http://itextsharp.cvs.sourceforge.net/itextsharp/ Alternatively you could file a feature request: http://sourceforge.net/tracker/?group_id=72954&atid=536239 Kind regards, Pete. From: Guillaume Chassigneux [mailto:[EMAIL PROTECTED] Sent: 12 November 2007 08:25 To: Peter Wheat Cc: 'THOLLOT Samuel' Subject: RE: SRQ071106600648 Hi Peter, I am coming back to you after this weekend, fully motivated ! So let's go : I tried the MM_ANISOTROPIC feature. My main issue here is that hidden formatting tags (rtf stream), I mean when we begin a bold section or end it, insert an extra white space in the final pdf file. You can see this behavior in the attached archive (temporary emf and wmf, final pdf file). The wmf and emf seem to be ok. Do you have any idea about this ? Thanks in advance, Guillaume -------------------------------------------------------------------------------- De : Peter Wheat [mailto:[EMAIL PROTECTED] Envoyé : vendredi 9 novembre 2007 12:47 À : Peter Wheat; Guillaume Chassigneux Cc : 'THOLLOT Samuel' Objet : RE: SRQ071106600648 Can you make this change to your code, and fix up anything else you can (e.g. EM_FORMATRANGE rect), and let me know if you are still hitting problems, and what they are. Thanks in advance. Kind regards, Pete. From: Peter Wheat Sent: 09 November 2007 11:45 To: Peter Wheat; 'Guillaume Chassigneux' Cc: 'THOLLOT Samuel' Subject: RE: SRQ071106600648 When using MM_ANISOTROPIC mapping I dont see the Bold down shift. See: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnargdi/html/msdn_mapping.asp From: Peter Wheat Sent: 09 November 2007 10:41 To: 'Guillaume Chassigneux' Cc: 'THOLLOT Samuel' Subject: RE: SRQ071106600648 In order to see the EMF pre-conversion (attached), I added the following code: [DllImport("gdi32.dll")] static extern uint GetEnhMetaFileBits(IntPtr hemf, uint cbBuffer, [Out] byte[] lpbBuffer); .... // Récupération du handle du fichier metafile de la page // Création du buffer IntPtr hEmf = img.GetHenhmetafile(); // To know what size should the buffer be uint emfbufferSize = GetEnhMetaFileBits(hEmf, 0,null); byte[] emfbuffer = new byte[emfbufferSize]; uint result = GetEnhMetaFileBits(hEmf, emfbufferSize, emfbuffer); FileStream fs = new FileStream(@"C:\\Users\\peterwh\\Documents\\rft.emf", FileMode.Create); fs.Write(emfbuffer, 0, emfbuffer.Length); fs.Close(); Although the capture rect is clearly too small (probably and earlier error in the capture rect), the EMF does not show the bold shift. So the problem must be in the conversion to WMF. I think we need to look GdipEmfToWmfBits and the parameters we are passing. Kind regards, Pete. From: Guillaume Chassigneux [mailto:[EMAIL PROTECTED] Sent: 09 November 2007 07:24 To: Peter Wheat Cc: 'THOLLOT Samuel' Subject: RE: SRQ071106600648 Hi Peter, Thank you very much for your usefull utility. I went a little further in my tests. During our rtf2pdf converting process using the vector approach as you mentionned I was able to save the temporary wmf file. You can find it attached with this email along with its resulting printed pdf file. You will notice in the resulting pdf file that the bold text appears shifted. Furthermore if you select the texte in the pdf (I am using Adobe Reader for viewing it), you will see a white non selected space before and after the bold text. I have loaded pipo-3.wmf in MFEdit and I could point out that the instruction that prints this bold text is the 27 one : EXTTEXTOUTW 284 0 418 ... this instruction is not very readable in the bottom of the interface, is there another way to get it more clearly ? It is an ALDUS metafile. I hope this helps. Waiting for your update, best regards _________________________________________ Guillaume CHASSIGNEUX Ingénieur Etudes et Développements Architecture et Composants Communs FIDUCIAL INFORMATIQUE - Direction des Produits Verticaux http://www.fiducial-informatique.fr 30, rue Sergent Michel Berthet - C.P. 102 - 69 266 LYON Cedex 09 -------------------------------------------------------------------------------- De : Peter Wheat [mailto:[EMAIL PROTECTED] Envoyé : jeudi 8 novembre 2007 18:21 À : Peter Wheat; Guillaume Chassigneux Cc : 'THOLLOT Samuel' Objet : RE: SRQ071106600648 Note that the most powerful feature of MFEdit is the single step play feature (i.e. one GDI command at a time). From: Peter Wheat Sent: 08 November 2007 17:12 To: 'Guillaume Chassigneux' Cc: 'THOLLOT Samuel' Subject: RE: SRQ071106600648 I will be looking at the vector approach first, as I believe this has the most chance of success. One thing we need to be sure of, is that the WMF file being put into the PDF file looks perfect. A tool I have found useful for investigating this type of problem in the past, is MFEdit (attached). Kind regards, Pete. From: Guillaume Chassigneux [mailto:[EMAIL PROTECTED] Sent: 08 November 2007 16:29 To: Peter Wheat Cc: 'THOLLOT Samuel' Subject: RE: SRQ071106600648 Hi Peter, Please find as an attachment a sample program of what we are trying to achieve. On the main form of it, you will see 2 buttons. The first one prints the richtextbox using a WMF graphics, the second one using a BMP graphics. Both buttons generate a pdf file in the root C:\ folder. Keep in mind that our goal is to propose a WYSIWIG editor, that is to say that the lines must wrap the same way in the final print and in the richtextbox and we want to display live page jumps while editing the richtext (as a moving glyph in the margin for example). Here are exposed our problems : With the "Vector" button : you will notice that all the rtf style markers appear in the final pdf as extra white spaces. Indeed almost all hidden markers behave like that. The lines' height of the result differ from the richtextbox. With the "Bitmap" button : Our problem here is specifically quality. Even if we try to increase the resolution of the temporary bitmap, it remains dirty. On the other hand, the lines' height match aproximatly with the richtextbox. Thank you very much for your attention and your efficiency. Best regards, _________________________________________ Guillaume CHASSIGNEUX Ingénieur Etudes et Développements Architecture et Composants Communs FIDUCIAL INFORMATIQUE - Direction des Produits Verticaux http://www.fiducial-informatique.fr 30, rue Sergent Michel Berthet - C.P. 102 - 69 266 LYON Cedex 09 -------------------------------------------------------------------------------- De : Peter Wheat [mailto:[EMAIL PROTECTED] Envoyé : jeudi 8 novembre 2007 11:07 À : [EMAIL PROTECTED] Objet : SRQ071106600648 Hi Guillaume, I am the owner of your case. Please can you send me a small sample program (with source), that demonstrates the problem observed. Many thanks in advance. Kind regards, Peter Wheat Microsoft Developer Support Tel. +44 (0)118 909 3463. _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://itext.ugent.be/itext-in-action/
