You are not logged in.
I seem to have found a problem rendering asian fonts, specifically something that requires simsun.ttc. I have an EMF file that I am trying to convert to PDF. Code looks like the following:
var
Doc: TPdfDocument;
Metafile: TMetafile;
begin
Doc := TPdfDocument.Create;
Doc.UseUniscribe := True;
Doc.AddPage;
Metafile := TMetafile.Create;
Metafile.LoadFromFile('test.emf');
Doc.Canvas.RenderMetaFile(Metafile);
Doc.SaveToFile('test.pdf');
end;
I can't see how to add an attachment, but I am happy to send "test.emf" in an email if you provide me with an address.
A range-check error is caused in SynPdf.pas, line 5647, in code:
procedure SwapBuffer(P: PWordArray; PLen: Integer);
var i: integer;
begin
for i := 0 to PLen-1 do
P^[i] := swap(P^[i]);
end;
It seems that PWordArray (length 16384 defined in sysutils) is too small for the Simsun font, though FWIW I have no experience with this library at all, and the fault could easily lie with me.
regards
cjrh
Offline
I'm always using range checking OFF in the compiler options.
Since there is a lot of pointer usage in these units, you should do the same.
The code should ever not work or compile at all for some units.
So here is the main rule:
Set range checking OFF in the compiler options
Your code will be faster, in all cases...
With FastMM4 as memory manager (standard since Delphi 2006 I think), the memory range errors are catched much more efficiently. So don't worry about setting range checking off.
Offline
With range-checking disabled, output is indeed generated. In my output PDF, however, I see that although the correct Asian text is now generated, the Arabic text is not right. An email, with attachments, has been sent to you about this. Thank you for your prompt feedback.
Offline
I didn't receive your email with the pdf nor the corresponding source code yet.
I just receive the ttf font. About the ttf font, I think setting range checking OFF fixed it.
I suspect there is a problem in your source code... could you post here the part used for generating the Arabic?
Offline
After analysing your emf file, it seems like it contains some opaque command which I didn't encounter yet: ETO_GLYPH_INDEX
Our engine doesn't handle this ETO_GLYPH_INDEX option.
If the ExtTextOutW function is called with this option, there is no text encoded, but the glyph index corresponding to the text...
How was your emf file created? Is it not possible to use standard text encoding?
I could try to add ETO_GLYPH_INDEX support if you really need it.
Offline
Here we are.... version 1.8 now should handle ETO_GLYPH_INDEX as expected...
See http://synopse.info/forum/viewtopic.php?id=28
and say if it's OK for you.
Offline
Looks perfect! Many thanks for your speedy fix! The emf was created by entering the text into Word, and then using a virtual printer to write printing commands to the EMF. I would love to follow development of this library (and perhaps contribute) by tracking a version-control archive. As far as I can see, you don't use one yet? I would recommend Git or Mercurial over Subversion.
Last edited by cjrh (2010-06-23 07:11:35)
Offline
I've added a version-control system to our site, together with a bug tracking and a wiki.
Offline