News form the PDF Library Laboratory

 

The samples should be checked for correctness [PDF Creator Pilot 547]

Sergius Bobrovsky: 05-12-2008 03:39
The samples should be checked. For most of the languages everything should be OK. There is a reason to suspect that the Delfi sample is not quite correct. It must be checked and fixed.

 

A problematic EMF [PDF Creator Pilot 546]

Artem Golubnichenko: 05-11-2008 23:05
This EMF-file contains a table. After conversion into PDF, the text in the table expands beyond the table borders.

 

Page mode switching is not transparent for the user [PDF Creator Pilot 545]

Vitaly Shibaev: 05-08-2008 01:08
For instance, we output a text, preserve current position, then we output an image and check current position of the text, and it is 0, although there is no reason for this, from the point of view of the user.

 

Problems with EMF files containing Greek characters [PDF Creator Pilot 544]

Vitaly Shibaev: 05-07-08 05:50
The old good problem. I've got some ideas how to correct this. After release.

Artem Golubnichenko: 05-07-2008 02:02
During conversion of EMFs, the words that contain Greek characters render with redundant word breaks, the characters themselves do not vanish. Roman characters in the same EMFs render OK.

 

An error during addition of controls with similar names. [PDF Creator Pilot 542]

Vitaly Shibaev: 05-06-2008 22:21
There is no handler for the situation when CreateControl is called with an existing name.

 

The release To-Do's [PDF Creator Pilot 540]

Vitaly Shibaev: 05-11-08 04:27
The (1) is done.

Sergius Bobrovsky: 05-06-08 23:37
It's been decided to put the (7) off until after the release.

Sergius Bobrovsky: 05-04-08 12:53
The (4) is done.

Vitaly Shibaev: 05-04-08 12:38
The (6) is done.

Sergius Bobrovsky: 05-04-08 11:51
Correction: the (5) isn't necessary, there is no such limitation.

Sergius Bobrovsky: 05-04-2008 06:36
1) Deletion of pages
2) Deletion of outlines
3) Deletion of unused objects
4) "Condensing" of xref before save (re-enumeration)
5) Save optimization of xref (in groups by 100 records)
6) Correct the case with the unnecessary object from the forms (that
is always written)
7) Balance the page trees
8) Documents merging
9) Improve API

if possible
10) Deletion of annotations

Test open and save with various documents, and how it works with the open document.

 

A problematic EMF-file [PDF Creator Pilot 539]

Artem Golubnichenko: 04-30-2008 05:38
In the source EMF-file we use Tahoma Italic to output a string. In the resulting PDF-file, instead of the text, there are black rectangles.

 

CMYK Tiff [PDF Creator Pilot 533]

Vitaly Shibaev: 04-17-2008 01:21
The library does not render TIFF images correctly into the CMYK contexts.

 

PdfException and the output window [PDF Creator Pilot 531]

Vitaly Shibaev: 05-04-08 09:21
Now, in case of unexpected PdfException, we write "Unhandled exception: information from GetErrorMessage()". I have inherited our class from the standard exception class.

Sergius Bobrovsky: 04-13-2008 14:15
It would be better if our own exceptions wrote in the Output window explanatory text, in the similar way as the standard exceptions do.
For that, I think, there must be a special method. Probably, we should inherit our PdfException class from a standard exception class, competently.

 

Looks like the annotation outline is ignored during generation of a PDF [PDF Creator Pilot 530]

Sergius Bobrovsky: 04-16-08 13:55
Results of the investigation:
- value of the outline width always equals to 1, and there not an API to change that value;
- it is impossible to control the curvature of the angles with the API;
- only annotations of the Link type support stroke dash patterns of the outlines. The standard implies that the patterns must supported for some other types of annotations, but these other types of the annotations are not supported by our API;
- outline pattern may be (according to the standard) specified with the tag "Border" or as a part of the tag "BS", we use only the first of them, the obsolete one. To specify both of them, we will have to add the code to convert the older format into the modern one (they differ, though slightly).

I don't close the ticket yet, we will have to resolve the problems above in the coming API.

Sergius Bobrovsky: 04-13-2008 14:10
If I got that right, there is no reaction to the types of angles and availability of an outline, and the outline values are ignored during the rendering.
That must be investigated, and fixed, if only possible.

 

Accompanying objects [PDF Creator Pilot 528]

Sergius Bobrovsky: 04-08-2008 06:18
I think we should remove term "the Object accompanying objects".

 

Use of Visual C++ 2008 Feature Pack, in particular TR1 [PDF Creator Pilot 527]

Sergius Bobrovsky: 04-07-08 16:01
I agree. In the next release we will use the smart pointers from TR1.

Vitaly Shibaev: 04-07-2008 15:43
We should create that subject here.

 

Impossible to save a document after PDF.PDFOUTLINES_Clear , Access Violation [PDF Creator Pilot 523]

Maxim Filimonov: 04-06-2008 23:04
Here is a sample:

Set PDF = CreateObject("PDFCreatorPilot3.PDFDocument3")
PDF.StartEngine "demo", "demo"
PDF.AutoLaunch = True
PDF.FileName = "test.pdf"

PDF.BeginDoc
lAction = PDF.CreateGoToPageAction(0, 0)
i0 = PDF.PDFOUTLINES_Add(0, "0", lAction, 0)
i1 = PDF.PDFOUTLINES_Add(0, "1", lAction, 0)
PDF.PDFOUTLINES_Clear
PDF.EndDoc
Set PDF = nothing

When we are at the EndDoc, an Access Violation fires:
void Dictionary::RemoveItem(const char* key)
{

map<string, Object*>::iterator iter = m_items.find(key); // <== here
if (iter != m_items.end())

One more crash was here:
void Dictionary::Add(const char* key, Object* obj)
{
...
if (m_items.size() >= HPDF_LIMIT_MAX_DICT_ELEMENT) // <== here

 

Font problems in an Editbox [PDF Creator Pilot 522]

Vitaly Shibaev: 04-04-08 03:27
The same problem may be observed in Acrobat 7 and 8.
Definitely, we can't do anything about underlines and strike-thrus in the near time. We must first learn to create underlined/striked fonts from the normal ones).

Maxim Filimonov: 04-04-2008 03:01
Look at this code fragment:

PDF.BeginDoc
PDF.PDFPAGE_CreateControl_Edit "edt1", 10, 10, 150, 30
PDF.PDFANNOTATION_Text = "Text"
PDF.PDFANNOTATION_Font_Name = "Times"
PDF.PDFANNOTATION_Font_Color = 255
PDF.PDFANNOTATION_Font_Charset = 0 'charsetANSI_CHARSET
PDF.PDFANNOTATION_Font_Size = 8
PDF.PDFANNOTATION_Font_Style_fsBold = True
PDF.PDFANNOTATION_Font_Style_fsItalic = True
PDF.PDFANNOTATION_Font_Style_fsStrikeout = True
PDF.PDFANNOTATION_Font_Style_fsUnderline = True
PDF.EndDoc

In the PDF that creates, I see the field and the text, as desired. If I select the field, all underlines and strike-thru's vanish. When I append "asd", I see these characters. After the focus is removed, instead of the new text there are squares.

 

It looks like PDF.PDFANNOTATION_Box_Y does not work [PDF Creator Pilot 521]

Maxim Filimonov: 04-04-2008 00:26
Here is the code:

' PDF object is supposed to be created
PDF.BeginDoc
PDF.PDFPAGE_CreateControl_Edit "edt1", 200, 200, 310, 223
PDF.PDFANNOTATION_Text = "Text"
PDF.PDFANNOTATION_Box_X = 10
PDF.PDFANNOTATION_Box_Y = 10
PDF.PDFANNOTATION_Box_W = 100
PDF.PDFANNOTATION_Box_H = 13
PDF.EndDoc

The field remains in the bottom, though it must have moved to the top.

 

GetUsedDC [PDF Creator Pilot 520]

Vitaly Shibaev: 04-04-08 03:09
OK, thanks!

Sergius Bobrovsky: 04-04-08 03:05
I don't know why it is there. I guess, for some calculations, or so. It is legacy from PDF Creator Pilot 2.x, Stas may know why Vadim created it.

Vitaly Shibaev: 04-04-08 02:53
OK, I get it. But why should anybody need to know which context was used as a base for creation of a virtual context?
Do we need that function at all?

Sergius Bobrovsky: 04-04-08 02:43
GetUsedDC() returns the base context that was used during creation of the virtual context.
HDC returns the virtual context itself.
These functions return different contexts.
I have checked the code, it looks to be OK. GetUsedDC() should not set the m_bVirtualDCUsed flag, because to retrieve a context that served as base for the virtual context does not mean to use the context.

Vitaly Shibaev: 04-03-2008 22:54
Will there be any difference in behavior between GetUsedDC() and HDC? After looking at its implementation, I think they should not differ. If this assumption is correct, then the current implementation of GetUsedDC() dies not work quite correctly. It does not set flag m_bVirtualDCUsed.
Or it is as it should be?

 

Misnamed parameters in annotation methods [PDF Creator Pilot 518]

Maxim Filimonov: 04-03-2008 02:50
In the following methods:

PDFPAGE_CreateControl_Button
PDFPAGE_CreateControl_Checkbox
PDFPAGE_CreateControl_Combobox
PDFPAGE_CreateControl_Edit
PDFPAGE_CreateControl_RadioButton
PDFPAGE_SetAction
PDFPAGE_SetAnnotation

the actual order of parameters (l, t, r, b...) differs from the specified (l,b,r,t...).
It must be changed in the code, in the docs. However, I did not do anything yet, since Vitaly makes intensive changes in the Page code, and if I do anything now, it would be very hard to check it back into the svn.

 

The PDFOUTLINENODE_Expanded property is ignored [PDF Creator Pilot 517]

Sergius Bobrovsky: 04-04-08 03:03
Fixed. Only the structure of the outlines took the openness of the outlines into account, and the property was saved only when it was open.

Maxim Filimonov: 04-03-2008 01:47
Even if I specify PDF.PDFOUTLINENODE_Expanded = False, the node remains expanded.

 

PDFPAGE_Scale misbehaves [PDF Creator Pilot 515]

Vitaly Shibaev: 04-04-08 04:20
I have completely rewritten all code dealing with the co-ordinates. Scale, Translate and Rotate now work fine. Tests show, that 0063.emf and 0066.emf started to convert incorrectly (due to the changes).
Comboboxes.vbs misbehaves, too - it requires minor changes, I will fix it a bit later.
There are problems with metafiles (TestAllResolutions, TestLogTextOperations, TestPlayMetafileOnDC, TestPrinterJob3).
Neither TestMu works right.
The ticket remains open.

Maxim Filimonov: 04-01-2008 05:44
Below there is a sample of code that misbehaves. I expected to see something different. This code neither shrinks nor expands the coordinates, it does something else.

Set PDF = CreateObject("PDFCreatorPilot3.PDFDocument3")
PDF.StartEngine "q", "q"
PDF.AutoLaunch = True
PDF.FileName = "test.pdf"
PDF.BeginDoc

PDF.PDFPAGE_SetGrayStroke 0
PDF.PDFPAGE_Rectangle 10, 10, 310, 210
PDF.PDFPAGE_Stroke

PDF.PDFPAGE_Scale 0.5, 0.5

PDF.PDFPAGE_SetGrayStroke 0.7
PDF.PDFPAGE_Rectangle 20, 20, 320, 220
PDF.PDFPAGE_Stroke

PDF.EndDoc
Set PDF = nothing

 

UseCurrentDocumentResolutionForNextPages deprecated [PDF Creator Pilot 514]

Sergius Bobrovsky: 05-03-08 13:55
Max! Please watch the tickets! ;-)

Sergius Bobrovsky: 04-01-08 05:00
Refreshment in the svn.

Maxim Filimonov: 04-01-2008 03:50
Property with a beautiful and short name UseCurrentDocumentResolutionForNextPages does nothing.

 

LastError fails to fulfil its duties [PDF Creator Pilot 513]

Sergius Bobrovsky: 04-01-08 05:43
Of course, do this after you are through with the docs.

Maxim Filimonov: 04-01-08 05:29
OK, I will. But I would prefer to do this after I finish with the docs, if possible. There is no end to similar samples in the doc.

Sergius Bobrovsky: 04-01-08 05:21
Max, would you look at it and fix this?

Maxim Filimonov: 04-01-08 05:15
Well, I was not quite right. LastError does return information about errors. However, not every function logs its errors.
For instance, if we attempt to load fonts from a non-existant file, no error is reported. It would be great to check such places. I keep from closing this ticket, just in case...

Maxim Filimonov: 04-01-2008 03:06
LastError always returns "", no difference whether there was an error.

 

Clip region for ExtTextOut [PDF Creator Pilot 512]

Vitaly Shibaev: 04-01-2008 02:44
Text in the left bottom corner fails to get cut.

 

Let us check whether our functions comply with GDI standards [PDF Creator Pilot 511]

Maxim Filimonov: 03-28-2008 03:56
Let's make sure that all our drawing functions behave as their GDI counterparts. I mean, we should draw lines from the current point to the first one, as in this sample:

PDF.PDFPAGE_MoveTo 10, 10
PDF.PDFPAGE_Arc 100, 100, 200, 200, 150, 100, 100, 150, (currentX), (currentY)

and so on.

 

Problems with an EMF-file [PDF Creator Pilot 510]

Artem Golubnichenko: 03-28-2008 00:34
Two more problems with conversion of an EMF.

 

Vertical text positioning in PDFPage [PDF Creator Pilot 506]

Vitaly Shibaev: 03-14-2008 13:04
Vertical positioning of text is sometimes inaccurate.
1) 0040.emf (the text above), 0090.emf(underlines and strike-through lines)
2) TestVerdanaCharsets from Tests.cpp - UnicodeTextOut(50, 0, 0, L"&http://www.colorpilot.com/mantisbt/view.php?id=218;&http://www.colorpilot.com/mantisbt/view.php ?id=209;&http://www.colorpilot.com/mantisbt/view.php?id=241;");

 

Loading a font named similarly to one of the Base-14 [PDF Creator Pilot 505]

Sergius Bobrovsky: 03-14-08 13:06
What if we check for availability of requested encodings? If that encoding is available in base-14, let us use that, if not - let us look for it inside the OS?

Vitaly Shibaev: 03-14-2008 12:58
For instance, some EMFs make use of Courier (in form of a system TTF- font). In such cases we must output text in that form of Courier, not in the Base-14 analogue. First it looks like there is no problem: we might look for the font in the System, and if there is no such font, look for it in the Base-14. :)
Unfortunately, the straight approach does not work. On my machine, for instance, a font named Helvetica gets successfully picked from the OS, (in fact, it gets replaced with Arial). We must think about it.

 

TestFontSizes in Tests.cpp [PDF Creator Pilot 504]

Vitaly Shibaev: 03-14-2008 12:43
In this test, the printer-based context is not rendered when resolution is set to 72.

 

Leak in CxMemFile::Alloc [PDF Creator Pilot 503]

Sergius Bobrovsky: 03-13-2008 04:29
This leak always happens whenever we use an image. We should examine the case.

 

It is problematic to convert an EMF-file [PDF Creator Pilot 502]

Artem Golubnichenko: 03-12-2008 13:40
There is an EMF-file that converts wrong, the files are here: [URL].

 

We should take the printer contexts only when it is necessary [PDF Creator Pilot 492]

Sergius Bobrovsky: 02-27-08 21:24
I have fixed this. If you run the TestLines test, you may look into the debugger's information about load of the system DLLs, and notice that the printer related DLLs are loaded only during creation of page 5, which is the first page in the test where the printer context is used.
Tests that don't use the virtual printer context, don't load these DLLs. Looks like this is fixed.

Vitaly Shibaev: 02-27-2008 03:52
We should never use the virtual printer contexts unless the user explicitly requests it.

 

The installer suggests to open the demo PDF even when it is missing [PDF Creator Pilot 488]

Sergius Bobrovsky: 02-19-2008 00:13
If we remove demo pdf and help from installation, at its final stage installer suggests to open them any way. That must be corrected.

 

Use of a font in the annotations [PDF Creator Pilot 483]

Vitaly Shibaev: 02-18-2008 14:39
The font that has been set using PDF.PDFANNOTATION_Font_Name = "Arial Unicode MS" isn't included into the PDF unless it is ever used to output a text with, e.g., PDF.PDFANNOTATION_Text = "".
This dependancy is a mistake.

 

AcroForm Submit [PDF Creator Pilot 478]

Vitaly Shibaev: 02-12-2008 14:16
Investigate problems related to AcroForm Submit.

 

Annotation and Charset [PDF Creator Pilot 465]

Sergius Bobrovsky: 05-03-08 13:56
Vitaly! Please watch the tickets! ;-)

Sergius Bobrovsky: 03-07-08 06:47
Fixed. Now it works like Outlines. Along the way I have re-factored some of the stuff, and removed several unused methods.

Vitaly Shibaev: 02-06-2008 03:03
Since SetAnnotation receives unicode input, it is not possible to use Charset there. I don't know how to fight that deprecated feature. I don't even think I would like to do that.

 

A pair of EditBox deficiencies [PDF Creator Pilot 464]

Vitaly Shibaev: 02-05-2008 10:49
1) A long "password encrypted" text is rendered as a single line (see the related ticket 0000463)
2) In case of the right alignment positioning is not precise. This deficiency is related with inaccuracy of the Text**Box functions.
3) In EditBoxes with the text length constraints, entire default texts that are longer than the limit are rendered.

 

Functions TextBox, TextOutBox and TextOutBox2 do not render ideally [PDF Creator Pilot 463]

Vitaly Shibaev: 02-05-2008 10:46
1) Positioning is not quite precise, for instance, in this case:
(Helvetica)
PDF->PDFPAGE_TextBox(100, 220, 130, 230, "Link", (TxHorJust)1, (TxVertJust)1);
2) Any text without spaces (even very large) is rendered as a single line.

 

Text output in the Edit fields of the AcroForm [PDF Creator Pilot 461]

Vitaly Shibaev: 02-04-2008 03:48
By default, text in the Edit fields is not shown unless the Edit field is focused. After any change to the text, this behavior disappears.

 

The parsers are not optimal when reading from the MemoryFile [PDF Creator Pilot 454]

Sergius Bobrovsky: 04-10-08 12:51
After we change lexer and parser, this won't be actual any more.

Sergius Bobrovsky: 01-30-2008 15:28
I suspect that, for instance, ReadLine, isn't quite optimal.

 

A problem in the EMF output [PDF Creator Pilot 453]

Artem Golubnichenko: 01-30-2008 12:33
When the attached EMF-file is converted into a PDF, in the PDF file some text is added between "Menge" and "Artikelbeschreibung". There is no such text in the EMF source file.

 

An EMF-file contained in the archive converts wrong [PDF Creator Pilot 452]

Vitaly Shibaev: 01-30-2008 04:20
An EMF-file contained in the archive converts wrong.

 

Code reorganization of Dictionary and DictionaryStream [PDF Creator Pilot 448]

Vitaly Shibaev: 01-23-2008 11:45
Let us implement these classes normally...

 

TestLineWidth does not work [PDF Creator Pilot 440]

Sergius Bobrovsky: 01-20-08 23:44
Thanks!

Vitaly Shibaev: 01-19-08 10:44
There was a bug in the converter (as usual, in one single line of code) - when we calculated the word spacing, we used the dpi of the EMF-file while we needed the dpi of the page.

Vitaly Shibaev: 01-18-2008 03:52
The same as the subject :)

 

A bad TIFF file. It fails to convert into PDF [PDF Creator Pilot 439]

Sergius Bobrovsky: 01-17-08 11:58
I agree that we must fix that bug ASAP. However, I don't understand how you will return that as unsigned char*. How can you know the size? Or that must be a separate function?

Vitaly Shibaev: 01-17-2008 10:49
The "wstring PDFDocumentImpl::get_OutputByteStream()" contains the following lines:

r_t* pData =....
wstring res = pData;

In the last line only a part of the array gets copied (probably, the copy halts at the first '\0'). This place should be fixed ASAP.
I think we should not cast data into wstring. We could return unsigned char* instead.

 

The library fails to work from ASP [PDF Creator Pilot 425]

Maxim Filimonov: 01-15-2008 08:47
There is a script and an image in the attachment. Output consists of an empty PDF, without the image. It is a TIFF (Jpeg).
Update: file, as usually, failed to attach (with a server error) It is here: [URL]

 

XMP and DocumentInfo do not comply with PDF/A [PDF Creator Pilot 420]

Vitaly Shibaev: 01-12-2008 10:52
There are for inconsistencies with the PDF/A:
1) CreationDate and xmp:CreationDate differ
2) For the fields Title, Author and Subject there must be dc:title, dc:creator and dc:subject.

 

Size of the Font Library [PDF Creator Pilot 419]

Vitaly Shibaev: 01-14-08 22:39
No, there is still a lot of candidates for reduction.

Sergius Bobrovsky: 01-14-08 19:55
Thanks! Are there some evident candidates for reduction? If there is none, let us close the topic?

Vitaly Shibaev: 01-14-08 13:22
The latest results:
Release - 9.6 MB
Debug - 11 MB

Sergius Bobrovsky: 01-14-08 01:14
I don't know. I would like to know.
PS I am not sure that Eugene reads our mails now.

Vitaly Shibaev: 01-12-08 11:01
Today I managed to reduce the size of the Release build from 21 MB to 11 MB. In the Debug build - from 12 MB to 11 MB. However, we still face a strange situation when the Release is bigger than the Debug. Now the difference is not very big at last. It means that there is a lot of opportunities for further optimization.
The main reason so far is the overuse of STL. For instance in a cpp- file we include "stdafx.h", and the pre-compiled headers are off. "stdafx.h" includes three more files - <string>, <map> and <vector>. It is using the "std" namespace. None of those collections is used, however, the object file in the Release build swells terribly. I don't know why: do you have any idea?

Sergius Bobrovsky: 01-11-08 23:58
a) It means that the lib will be yet smaller
c) It looks like we do use something: otherwise I can't imagine where could it take those 20 MB?

Vitaly Shibaev: 01-11-08 23:48
a) the 4 source files are 2.11 MB large
b) We need to use MyArray, but probably, we may manage without it. I will think about it...
c) No, ATL, WinGDI and COM are not used.

Sergius Bobrovsky: 01-11-08 09:30
a) what is the size of the tables? What is their contribution to the size of the library?
b) do we need MyArray?
c) do we use in the library ATL, WinGDI, COM?

Vitaly Shibaev: 01-11-08 06:00
Well, the size may be that large because of:
a) There are several larger tables in the library that contain the encoding data. Actually, if we make everything to be in Unicode in PDFMosaic (in C++), we will not need those tables any more. It is again the same old question about independent use of the existing PDFCreator.sin in PDFMosaic.sin. PDFCreator requires that data.
b) The MyArray<T> template swell. It is used in too many places, with various arguments for T. It is possible that if we use, for instance, MyArray<char> in two different places, it generates two separate classes.
We must investigate it.

Sergius Bobrovsky: 01-10-2008 22:18
Why is the font library (MyFontLib) 10-20 MB large, while CxImage is 1-5 MB large.
We should reduce the size.

 

[Feature Request] We must support the CFF fonts [PDF Creator Pilot 415]

Sergius Bobrovsky: 01-08-2008 22:12
I think we will be very good after that. ;-)

 

Text underline and horizontal scaling [PDF Creator Pilot 414]

Vitaly Shibaev: 01-07-2008 12:19
When a line is rendered, HorizontalScaling is igonred.

 

2 EMF-files fail to convert [PDF Creator Pilot 413]

Sergius Bobrovsky: 01-09-08 00:19
There is a problem in the first file with the fill. As well, it renders some crap instead of the Greek text. I did not look at the second file yet (it is not that important right now).
We should fix the problems around fills and patterns at last, otherwise we would have to spend all our time fine-tuning the library.

Sergius Bobrovsky: 01-08-08 22:40
Looks like there is a problem with the color spaces. I go on with the investigation.

Vitaly Shibaev: 01-07-2008 02:32
The converted documents are empty.

 

[Feature Request] Fills [PDF Creator Pilot 411]

Sergius Bobrovsky: 12-31-07 04:24
See ticket 0000013.

Sergius Bobrovsky: 12-31-07 04:22
This request has been registered, and Stas was assigned.

Vitaly Shibaev: 12-31-2007 02:23
We should implement the pattern fills.

 

Outlines are not Unicode [PDF Creator Pilot 409]

Sergius Bobrovsky: 03-06-08 13:52
I have investigated the problem with assistance of Vitaly. Now we follow the same pattern as with output of the ordinary text: if it is possible to output string with no encoding we output it "as is"; if it needs an encoding service, we use it; if it is a Unicode string, we output that string as Unicode. Under this approach, no text gets cut and lost, any combination of text and encoding works fine.
I have added some code into the test to check right that, everything works as expected.

Sergius Bobrovsky: 12-27-2007 03:58
We must make outlines unicode, in order to use them with different languages.

 

PDFDocumentImpl: non-rational data store [PDF Creator Pilot 408]

Sergius Bobrovsky: 12-27-2007 03:11
In the containers we should store pointers to the objects, instead of their copies. It would be great for memory and efficiency. As well, we could eliminate extra #include statements in the interface.

 

Elimination of ATL in PDFLib [PDF Creator Pilot 407]

Sergius Bobrovsky: 12-27-2007 02:16
This way we could avoid several warnings, decrease the number of dependencies and the size of the library.

 

Document properties are not in Unicode [PDF Creator Pilot 406]

Sergius Bobrovsky: 12-26-2007 23:02
We must make the properties unicode, in order to use whatever language, say, in the keywords, not just English + Local (In Russia, Local = Russian).

 

Transparency, alpha channel [PDF Creator Pilot 400]

Sergius Bobrovsky: 01-14-08 09:24
There exist GDI+ -only EMF files, however, GDI+ is usually converted into a set of GDI commands.

Vitaly Shibaev: 01-14-08 06:08
By the way, does our context support GDI+? I ask that because things look differently in the code and in the EMF. It must be an EMF+, isn't it?

Sergius Bobrovsky: 01-12-08 00:15
I did not think to these details yet. Probably, because there was a BMP-file. If there was a PNG-file, it would be differently. Any way, use EMF for orientation.

Vitaly Shibaev: 01-12-08 00:07
OK, thanks!
And why the images (those that are BMP when on the disk) are created differently (not as in the metafile)?

Sergius Bobrovsky: 01-12-08 00:00
Take the fresh variant.
I have just added 0089.emf - it is what they are rendering to the virtual context of the library. Compare that with what we get in the PDF file. All doubts about where it renders correctly and where it does not should disappear. :-)
Transparency (by itself) is not used here. The images draw with DibPatternBrush (that we don't use) and special flags.

Vitaly Shibaev: 01-11-08 23:52
Why should it look differently, not like the pictures? And why the right hand picture is normal?
The lib does not support transparency, so they can't render correctly.

Sergius Bobrovsky: 01-11-08 09:49
I see. Well, it generates the pictures, but they must look differently any way.
First I was sure that there is a problem with the rightmost picture (black bordered), but then I understood that it is the other one (the red square) isn't good. It must consist of dots, too.
I have added that EMF to the collection of tests. Problem should resolve after we implement the pattern fills (they are used here).

Vitaly Shibaev: 01-11-08 05:45
There is a project in the archive. Compile it, and then it will produce a PDF file and two pictures. These pictures must look like those in the PDF file.

Sergius Bobrovsky: 01-11-08 05:12
Could anybody explain, what is wrong with the attached PDF? and what does the client want? By the way, there is no picture in the archive.

Vitaly Shibaev: 12-24-07 14:28
We should notify a user on beginning (or completion) of our response to this feature request.

Vitaly Shibaev: 12-24-2007 14:13
We should add support of transparency.

 

To-Do's for the release [PDF Creator Pilot 397]

Vitaly Shibaev: 12-27-07 12:58
All "To-Do's" have been done.

Vitaly Shibaev: 12-20-2007
1) There must be no leaks during the execution of tests. Leaks of type "????" in the memleaks.log may be ignored for a while, I think.
2) We must test everything - Tests.cpp, VBS samples, testcase, all test units in the UnitTests, in both, Release and Debug.
3) Get rid of as many Windows-specific classes as possible
4) Replace the System font with Arial

Extra wish-list (probably, for the next version)
1*) Sergey should look at the bug;
2*) Support of CMYK JPEG.

 

A bug in the user's script [PDF Creator Pilot 395]

Vitaly Shibaev: 12-20-07 06:03
I see, thanks!

Sergius Bobrovsky: 12-20-07 05:51
I get the text of the expected sizes.
The results may differ because the Emf2Pdf adjusts converter so that the resolution and dimensions of both PDF and EMF were the same.
In the attached script the PDF resolution is set to the default one (72 dpi), while the page is set to be very huge (7008x4958). As a result, the text is very small.
This can be resolved by either setting the proper coefficients in the PDFPAGE_PlayMetaFileExFromFileName (compress them) or by increasing the page resolution of the PDF-page, like this:

PDF.Resolution = 300
PDF.BeginDoc

The resolution should be set before the BeginDoc and NewPage.

Vitaly Shibaev: 12-20-07 05:13
And the text below is of the normal sizes? I get radically different results with Emf2Pdf and vbs.

Sergius Bobrovsky: 12-20-07 04:17
I have had a look, and I could not reproduce the bug.

Vitaly Shibaev: 12-19-2007 07:44
Emf2Pdf converts the EMF-files from the archive correctly, the vbs- script does not.
Probably the script needs a fix. Sergey, please have a look.

 

A build-server is needed [PDF Creator Pilot 394]

Sergius Bobrovsky: 12-18-2007 05:10
We must create a complex that would import updates from SVN (for instance, after every commit), then it would perform the build, and upload the result onto the ftp (nightly builds).

 

It would be great to enhance our site with "Send us an EMF, and we will convert it into a PDF" [PDF Creator Pilot 393]

Maxim Filimonov: 02-14-08 23:55
We will adjust this stuff as we go.

Sergius Bobrovsky: 12-18-2007 05:08
It is unclear, though, whether it would overload the server or not.

 

It would be great to enhance our site with "Send us a Font and a line of text, and we will convert it into a PDF"... [PDF Creator Pilot 392]

Maxim Filimonov: 02-14-08 23:55
We will adjust this stuff as we go.

Sergius Bobrovsky: 12-18-2007 05:06
and below there would be a list of Fonts (the last 25) sent by the users.

 

The color profiles of images must be supported [PDF Creator Pilot 390]

Vitaly Shibaev: 12-27-07 13:01
A temporary solution: now we just save them into file "as is". I am not sure whether this may be considered as a solution.

Vitaly Shibaev: 12-16-07 22:31
It would be great to resolve this problem before the 27th of January, 2008.
A client needs this feature badly.
Are we in position to resolve it in time?
The image is attached.

Sergius Bobrovsky: 12-14-2007 21:16
Our [potential] clients requested that feature many times. They ask what they could do to prevent conversion of CMYK images into RGB.
As far as I know, it is critical for pre-press that the color was calibrated once and forever. No manipulation with the calibrated images should change their colors.
Let us investigate, what do we miss (or what do we do from what we should not have done).
We need image samples from the clients.
We ought to improve the product.

 

MainDemo.vbs and RegisterForm.vbs should be refreshed [PDF Creator Pilot 386]

Sergius Bobrovsky: 12-13-2007 03:50
Both of these scripts draw a form with radio-buttons. It renders buttons and text separately, in the obsolete way. We should make them use the newer approach. The new one is more clear and better.

 

Incorrect processing of Type1 font unicode output [PDF Creator Pilot 384]

Vitaly Shibaev: 03-02-08 22:44
It is possible to see this now, for instance, in TestType1FontWithManyEncodings test.

Sergius Bobrovsky: 12-12-2007 06:32
Currently, the library fails to process correctly attempts to output a unicode text with a Type1 font. For instance, when we try to output a Russian text with Helvetica, we get junk symbols.
It would be better to render nothing in such cases and return an error code.
A return code should be also returned even in cases when a single glyph did not pass.

 

The library hangs [PDF Creator Pilot 0000383]

Sergius Bobrovsky: 01-08-08 22:30
I have attached the resulting PDF. The conversion takes a lot indeed: it took my computer 3.5 minutes to convert.
That EMF file is a kind of "degenerated". There is a lot of font selection commands following one another, for instance. The converter has to parse all those commands and it takes a lot of time. If the EMF-file was ok, (not for those redundant GDI-commands), there would not be any problem at all.

Vitaly Shibaev: 01-04-08 11:44
I have checked it with the current build. Everything is OK. It works long, but the EMF file is very large, too.

Eugene Starkov: 12-11-2007 03:56
The library hangs during attempts to convert the attached file. The issue was checked with build 580.
It is a screenshot, printed by the virtual printer. The application that printed it out is unknown, and the users refuse to provide us with that information.

 

Import of CSV-files [PDF Creator Pilot 0000378]

Sergius Bobrovsky: 12-06-2007 00:44
CSV files often contain extractions from Excel lists and databases. It would be a great opportunity for the library to be able to import such files, with page separation and spreadsheet look.

 

Custom flavors for controls [PDF Creator Pilot 377]

Sergius Bobrovsky: 12-05-2007 20:20
It would be great to allow custom favors of buttons, checkboxes and radio-buttons.
First, somebody has already asked us to use the mark in a checkbox instead of the cross Second, the standard colors don't fit all
As far as I know, it is possible The question is how to make it easy to use. The other question: what should be made mutable and how.

 

Web-languages samples [PDF Creator Pilot 369]

Sergius Bobrovsky: 12-05-07 6:50
We need samples demonstrating the use of the library from Ruby, php, Perl. It is desirable to design the samples as small articles.

 

[Feature Request] DLL-version [PDF Creator Pilot 0000368]

Sergius Bobrovsky: 12-05-07 6:54
We must develop a DLL-version of the library, to be able to use it without its registration and COM.

 

Size of the static version of the library [PDF Creator Pilot 367]

Sergius Bobrovsky: 12-04-07 6:51
Currently, the static version of the library is too large. Its size is rather inadequate. The size makes upload of the library to the site.

 

[Feature Request] The Linux version [PDF Creator Pilot 0000366]

Sergius Bobrovsky: 12-03-07 6:54
We should develop the Linux version of the library.

 

[Feature Request] The user defined metadata [PDF Creator Pilot 365]

Vitaly Shibaev: 12-03-07 6:54
The user must be able to add custom metadata into a document.

 

[Feature Request] Radio-buttons with text [PDF Creator Pilot 364]

Sergius Bobrovsky: 12-09-07 12:24
Thanks! It is what we needed.

Vitaly Shibaev: 12-07-07 03:54
One may check this with TestRadioButton or TestAcroForm in the Tests.cpp.
I have refreshed the RegisterForm.vbs; the check requires a rebuild.

Sergius Bobrovsky: 12-01-07 01:43
It would be great to make the radio-buttons with text. Now it is inconvenient, because we have to separately output the text. It brings us additional problems with positioning, etc.

 

A crash in the library [PDF Creator Pilot 0000357]

Maxim Filimonov: 12-29-07 04:29
All is OK.

Vitaly Shibaev: 12-27-07 13:06
The EMF files don't crash in the newest build.

Sergius Bobrovsky: 11-29-07 23:09
Every build after the build 580 is not stable.

Maxim Filimonov: 11-29-2007
The library crashes while converting these 4 EMF-files. See the attachment.

void PDFDocumentImpl::cleanUpHDocument()
{

delete m_xref; // <---- the library crashes here
m_xref = 0;

...

}
What is the number of the latest stable build?

 

Changes to apply to the processing of fonts [PDF Creator Pilot 337]

Vitaly Shibaev: 11-28-07 11:18
I have implemented the (3) and the (2).
I did not implement the (1) yet, since there is no special need in it.

Vitaly Shibaev: 11-26-07 07:03
I have implemented the (4) and the (5).

Vitaly Shibaev: 11-21-2007 07:36
1) We need to add support of composite objects (objects that consist of several sub-objects). PDFFont will be one of such composite objects;
2) Let the document creates a font, and the Page takes the fonts from the document, with the FontsManager knowing nothing about the font.
3) Let us register all objects required for the font when it is created;
4) To simplify the above, let us always create a fixed number of objects for a font (let the output always be Unicode);
5) Let us do the (4) only if we make that all into the normal implementation (see "text.doc output implementation").

 

Synthesized bold and italic [PDF Creator Pilot 336]

Eugene Starkov: 11-21-2007 01:29
There is an old problem with rendering in bold and/or italic of fonts where these typefaces are not defined.
GDI renders them, the library does not. For instance, in the 0002.emf italic gets lost during conversion.
It is the time to do something about this.
Vitaly, you promised to look into that when you have time :)

 

[Feature Request] Headers and Footers [PDF Creator Pilot 335]

Sergius Bobrovsky: 11-21-2007 00:43
It would be great if we could define page headers and footers.

 

[Feature Request] API to conveniently add tables [PDF Creator Pilot 334]

Sergius Bobrovsky: 11-21-2007 00:41
Quite often we are asked how to add a table into a PDF.
I think we must implement such API.

 

An Arabic font [PDF Creator Pilot 322]

Eugene Starkov: 11-15-2007 06:21
An Arabic fonts converts wrong.

 

Hidden text lines [PDF Creator Pilot 321]

Eugene Starkov: 11-20-07 00:04
It works!
8.8 pounds of thanks!

Sergius Bobrovsky: 11-19-07 13:13
I have changed this in the SVN, but don't use the latest build because it is not stable.
Just find in the method:
void CEMF2ChipConverter::BitBlt(const ENHMETARECORD* pEMFR)
this line of code:
if ((lb.lbColor & 0x00FFFFFF) == 0x00FFFFFF)
and change it into this:
if ((lb.lbColor & 0x02FFFFFF) == 0x02FFFFFF)
Everything must be OK, as far as I see I did not spoil anything.

Eugene Starkov: 11-14-2007 00:35
The attached EMF-file contains lines of text that have been covered by white rectangles (erased), and above those rectangles there was entered another text. Generated PDF reveals both, those that have been erased, and those written above them. That results in a terrible mess.

 

The library crashes when there is no space to save a file [PDF Creator Pilot 0000320]

Eugene Starkov: 11-14-2007 00:15
The library crashes when it is impossible to save a file because of no space on the disk. We should either catch that exception, or provide an informative message. We have already discussed informative exceptions. I think, now we must implement them.

 

A problem with embedding of CMYK images [PDF Creator Pilot 317]

Vitaly Shibaev: 01-14-08 05:50
Everything works fine in the latest release. As far as I understand, it was a question from a client of the Virtual Printer?
This client may be notified that his problem has been solved.

Eugene Starkov: 11-13-07 01:22
Files are here: (an URL)
Mantis stopped to attach larger files. It reports "APPLICATION ERROR http://www.colorpilot.com/mantisbt/view.php?id=500". File upload failed. Most probably it failed because the size of the file was larger then the PHP configuration permits.
Stas, check that please!

Eugene Starkov: 11-13-2007 00:59
A user complains that the library stopped to correctly embed CMYK- images. The user compares v 3.8 against v 3.2. One can see the difference in the Acrobat, too. There is Advanced- >Print Production->Output Preview. In that window one can manually uncheck specific CMYK channels, and it is obvious that the colors of the images are intermixed.

 

Type 1 once again [PDF Creator Pilot 316]

Eugene Starkov: 11-06-07 11:23
It works!
Thanks!

Vitaly Shibaev: 11-06-07 07:22
Eugene, take TrueTypeFontData::LoadOpenTypeFont, FontData::Create and PDFFont::Create from the current version.
In CFontsManager::loadFont, in the end of the code:

if (font == 0)
{

delete[] pBuffer;
lBufferSize = 0;
return 0;//change this

}
replace "return 0;" with "return getDefaultFont();"
I think that must work.

Sergius Bobrovsky: 11-06-07 07:08
As far as I understand, there is NO suppressor. There is nothing to put in the code.

Eugene Starkov: 11-06-07 07:02
I mean, if there is not too much code in the suppressor, I would put it inside my copy of the code, and then compile.
I just need that somebody pointed me into the right place.

Sergius Bobrovsky: 11-06-07 06:58
The build 580 is a working one.
I did not understand that "I will make the suppressor here".

Eugene Starkov: 11-06-07 06:52
Well.
Can I take build 580 from you, and make it into a special build (with the suppressor) here?

Sergius Bobrovsky: 11-06-07 06:48
There is no CFF fonts suppressor :-(
You are not right about the 593, either.

Eugene Starkov: 11-06-07 06:46
I see. But I need the CFF fonts suppressor.
I looked into the logs, it seems that build 593 was created before the massive reorganization.

Sergius Bobrovsky: 11-06-07 06:41
Just in case:
To never get errors like "... once again", don't use builds after the build 580. We are in the process of massive code reorganization, and there may be lots of bugs.

Eugene Starkov: 11-06-2007 06:38
Me and a customer, are both observing some strange crashes.
When we open in EMF2PDF the EMF file that's attached, first time it gets converted fine, but the next time we press Convert it fails and crashes.
I am working with the build 593, since I need the CFF fonts suppressor.

 

The Chinese hieroglyphs [PDF Creator Pilot 315]

Vitaly Shibaev: 11-29-07 12:00
The situation is absolutely vague. The text gis rendered into the EMF- file in plain Arial. The Sans Serif font that gets created never becomes current during the output. Arial contains no CJK-glyphs. We may conclude that the text was rendered with Arial Unicode MS. I have checked: it is true. If we force the EMF to output in Arial Unicode MS, everything looks fine.

Eugene Starkov: 11-06-2007 05:08
There is some Chinese text, written with Arial and Sans Serif, in the attached EMF file.
In any EMF viewer, the text is rendered, but after conversion into PDF we get squares instead of hieroglyphs.

 

An artefact [PDF Creator Pilot 312]

Sergius Bobrovsky: 01-11-08 08:10
The glitch is a part of two images, used in the EMF (half of the image in one image, the other part - in the second one). Somehow, a strange technic has been applied to the EMF: cutting the image when the output dimensions are less than the real dimensions of the image.
Now I check such cases separately, and process them.

Eugene Starkov: 11-01-2007 23:28
Some raster artefact.

 

Blackness 2 [PDF Creator Pilot 311]

Vitaly Shibaev: 11-02-07 07:04
Well, this problem is not mine. The text renders not as text, but as a drawing.
There is a problem with the fonts anyway - but it is not possible to resolve it. The third line from the top in the output file contains text Bembo. Windows Viewer just outputs not what it must, and we do the same.
The text is output through the indices of the glyphs, and we can't output anything in Type1-fonts as Unicode. You may read the .doc-file in the project root.

Eugene Starkov: 11-01-2007 23:26
Black rectangles instead of symbolic fonts.

 

Fill [PDF Creator Pilot 310]

Eugene Starkov: 11-01-2007 23:24
There is a problem with fills.
Sergey, is it the same problem with the pattern brushes? Is it hopeless?

 

Text disappears [PDF Creator Pilot 309]

Eugene Starkov: 11-01-2007 23:17
Text in the gray line of the table disappears.

 

Blackness [PDF Creator Pilot 308]

Eugene Starkov: 11-01-2007 23:16
All text in a page turns into black rectangles.

 

TTF Fonts with problems [PDF Creator Pilot 306]

Vitaly Shibaev: 12-31-07 05:10
The library does not support CFF fonts until now.

Sergius Bobrovsky: 12-31-07 04:50
And how is it now? Does the library works with the fonts as expected? Does it require more corrections?

Vitaly Shibaev: 11-02-07 15:08
I did it. Now everything is as Sergey described in (597) and (0000600).

Sergius Bobrovsky: 11-02-07 08:02
On attempts to embed a commercial font, we should mark it as NotEmbed.
We should not install such fonts.
In case of PDF/A?
If we do as I wrote above, there will be no problem.

Vitaly Shibaev: 11-02-07 07:49
Sergey, please clarify: in case of an attempt to embed a commercial font, should we mark it as NotEmbed (i.e., rely on availability of that font in the OS)? What should we do in case of PDF/A?

Vitaly Shibaev: 11-02-07 07:45
OK, this is what I will do.

Sergius Bobrovsky: 11-02-07 07:32
I suggest variant (c) - never change fonts when the new one can't be installed. And never embed it.

Vitaly Shibaev: 11-02-07 07:28
Then I suggest to review all complex of alike situation:
1) If the user attempts to embed a commercial font, we replace it
with Arial
2) If a font is not available in the OS, we replace it with Arial
3) For now, we replace fonts of unsupported formats (CFF) with Arial

Often such changes are not quite good: the font being replaced differs from Arial in its look, and the result looks ugly (0034.emf, 0035.emf look this way on my computer; I did not install that font). When the look of the fonts does not differ too much, the result becomes satisfactory.

Variants:
a) leave that problem alone and change nothing
b) change something (for instance, just exclude text in these fonts from output)

Sergius Bobrovsky: 11-02-07 07:10
Is there anything in the To-Do list for today? There is a problem, it must be solved.
There is no need to fix the holes.
If it fails, instead of replacing those fonts with Arial we should just return S_FALSE, without changing anything. The user will have a chance to understand that something does not go well.

Vitaly Shibaev: 11-02-07 07:06
I agree. However, it is better when the library does not crash. It isn't a short task to add support for such fonts.

Sergius Bobrovsky: 11-02-07 06:50
At my opinion, it is a dead-end solution.
It is better to make the library read such fonts. Clients are in position to replace fonts by themselves.

Vitaly Shibaev: 11-02-07 06:42
I've implemented a temporary solution: I replace CFF fonts with Arial. Then, the library stops to crash, and the result is not bad.

Vitaly Shibaev: 11-02-07 04:09
These fonts are based on CFF (Compact Font Format), our library can't work with them... for now.
Scarcely I will fix that, but I start to dig.

Eugene Starkov: 11-01-2007 23:08
Yet more fonts that crash the library.

 

PDF/A sees two problems with the font glyphs [PDF Creator Pilot 304]

Vitaly Shibaev: 10-31-2007 11:17
During Adobe Preflight, there was a diagnostic message that widths of one of the glyphs of Code39 TT in 0083.emf and of two of the glyphs in bembo.pfb are not adequate.

 

Temporary Adobe Acrobat fonts are not compatible with PDF/A [PDF Creator Pilot 303]

Sergius Bobrovsky: 12-31-07 04:53
Have anything been figured out?

Vitaly Shibaev: 10-31-2007 11:15
While 0047.emf and 0048.emf files are converted fine, there is a warning issued during Preflight that states "The font contains more than one cmap.
It is really so: the PDF Reference tells that "... The font descriptor's Symbolic flag (see Table 5.20) should be set, and its font program's "cmap" table should contain a (1, 0) subtable. It may also contain a (3, 0) subtable;..." The last phrase is the most important.
In the PDF/A standard, on absolutely the same, is said "...their font programs' "cmap" tables shall contain exactly one encoding".
Temporary Adobe Acrobat fonts consist of exactly two cmaps, and they are symbolic.
So we have to figure out how to fix that.

 

Type1 fonts hang up the library. [PDF Creator Pilot 301]

Eugene Starkov: 10-30-07 07:44
Mantis seems to glitch when encounters larger attachments.
Download it from here: [link]

Eugene Starkov: 10-30-2007 07:42
Type1 fonts hang up the library.
The EMF file and the fonts are attached.

 

Missing image [PDF Creator Pilot 300]

Eugene Starkov: 10-30-2007 04:22
An image inside the EMF file is not rendered in the PDF.

 

Subject: Report [PDF Creator Pilot]

Vitaly Shibaev: 10-26-07
Hi all,
I have fixed the crashing bug (that used to happen during conversion of TestCourier and TestBase14FontsEmbedding). I got rid of two cases of unnecessary memory allocation in FontLib. That has positively affected efficiency: now the entire testcase converts in the Release version in less then 40 seconds (with previous record being 46 seconds for the set excluding files 0080 and 0081). I've searched FontLib for leaks, and did not find any.
Then I have refreshed the documentation and the code for the RectRotated and the RoundRect. I still need to correct documentation that describes various methods of text output, and the CurveTo.
Then I've delved into resolving the "junk in the clipboard" bug. The buffer got filled with junk in the only case of Unicode output. This might have been resolved by using the usual output everywhere it was possible. I did that, and now it works fine, with the single exception of the Acrobat fonts. It remains to be done yet, but I will finish that on Monday.

Maxim Filimonov: 10-23-07
Hi,
I am reading the book (Martin Fowler. "Refactoring. Improving the Design of Existing Code."), and re-factoring my code. Several times I have asked myself: "who has written about that?", and rejected my own question. The very fact that I have asked myself that question brought me to understanding, that I am one of the "readers" of my own code.
I started to feel somewhat sad, wishing my hardest to improve the world.
Anyway, as Martin Fowler states, refactoring is not a one-time activity. It must be applied on a constant basis, as the code grows.
Now I am learning to think this way. I have separated some code into the other files. In order to elimitnate duplication of code, created a new class to work with XML elements and attributes. I have also rewritten code that saved documents to their files, and some related methods as well. Some methods have gone, some new methods have been added.
As a result, I may see 2 good signs: 1) looking at the code, one can easily tell what a specific method is doing and 2) it seems now that all methods do nothing at all, just call each other.
It is just the beginning, and I would not claim that it goes easily (it is about changing some habbits, that's very hard), there is a lot of obscure places in the code yet... Anyway, I am sure that everything will be fine.

 

Passwords [PDF Creator Pilot 297]

Sergius Bobrovsky: 01-11-08 09:27
I have added TestUserProtection to the collection of the tests. It creates a user password, and outputs a line of text. When we open that file in Acrobat, all operations are permitted for the file.
Looks like the problem has resolved by itself.

Eugene Starkov: 10-30-07 05:28
Is it possible to apply no security at all if only the User Password has been set? Otherwise we get into a strange situation: there is no security password, but printing, copying and modification are all locked? Acrobat does not do anything with security in such cases.

Sergius Bobrovsky: 10-26-07 10:22
Investigation revealed, that:
1) password may be of any length
2) any single password (of these two) is sufficient
3) if there is no Owner Password, while the User Password exists, the
Owner password is considered to be equal to the User password.

Eugene Starkov: 10-25-07 03:43
It is attached. Password is "zzz".

Sergius Bobrovsky: 10-25-07 03:36
I am not sure that the Owner password remains empty. May we look at an Acrobat file with onle the User password set?

Eugene Starkov: 10-25-07 03:30
Acrobat uses them as independtnt on each other. If we set the User password, the Owner password remains empty and permissions remain intact. Did we miss something important in our implementation?

Sergius Bobrovsky: 10-25-07 03:22
It is possible to make that the User Password worked as the Owner Password, too.

Eugene Starkov: 10-25-2007 03:17
There is something wrong with the PDF passwords in our product. The User password fails to work without the Owner password set. When only the User password is set, it is never reuested when the file gets opened.Adobe Acrobat respects both of them. One can install the opening password, and it works fine without any password for permissions.

 

Copy to clipboard [PDF Creator Pilot 296]

Eugene Starkov: 10-30-07 07:21
Everything seems to work. Thanks!

Vitaly Shibaev: 10-29-07 10:18
I've fixed this. Now, whenever possible, instead of Unicode output we use the plain text one. Exception: the CJK fonts, they output as Unicade all text, even the ANSI. One more situation when copy does not function as required: it happens if we copy a text not in standard encoding. For instance, in case of Cyrillic, as a rule we get senseless characters instead of it. We are not alone in this: I have seen a Tex file, where it looks very much alike. Copying into clipboard is guaranteed to work with the first 128 symbols of the table, all other values (i.e., Unicode and 8-bit encodings) are a problem of Acrobat.

Eugene Starkov: 10-25-07 06:42
The problem occurs, as it seems, only with PDF files converted from EMF.

Eugene Starkov: 10-25-07 06:41
I forgot to attach the file, sorry.
We viewed that with Adobe Reader. Attempted to paste in any text editors. Instead of characters we get just horrible shapes in the clipboard.

Sergius Bobrovsky: 10-25-07 03:21
Is it possible to provide us with more details? Which file, what has been used to view that, where did you intend to paste that?

Eugene Starkov: 10-25-2007 03:09
When we copy some text from a PDF file that has been generated by the library, we get some scrap in the clipboard.

 

TestBase14Embedding2 test crashes [PDF Creator Pilot 0000293]

Sergius Bobrovsky: 10-24-2007 07:08
Sometimes the FontsManager becomes incorrect, and the stack gets corrupted.

 

TestMetafileImagesCompression fails to work correctly [PDF Creator Pilot 292]

Sergius Bobrovsky: 12-31-07 04:41
There was a problem with the resolution. In the test, not in the library.

Sergius Bobrovsky: 10-24-2007 03:33
The test results in a file of adequate size, but the pages seem to be empty.

 

Subject: TestCourier test fails [PDF Creator Pilot 291]

Sergius Bobrovsky: 10-24-2007 03:28
The problem seems to be here:
IAnsiPDFFont* CFontsManager::GetANSIVersionOfTheCurrentFont()
{

return getCurrentFont()->GetANSIFont();

}
getCurrentFont() returns 0.

 

TestScripting test fails [PDF Creator Pilot 290]

Sergius Bobrovsky: 10-24-2007 07:07
Sorry, wrong destination. This test works fine!

Sergius Bobrovsky: 10-24-2007 06:57
It fails anyway. The FontsManager becomes invalid at some moment, and the stack gets corrupted.

Vitaly Shibaev: 10-24-2007 05:46
A nice test that helped to discover some failures in parsing of pfb files. The failures have been corrected.

Sergius Bobrovsky: 10-24-2007 01:03
TestScripting fails since because of an unknown problem in processing of Type1 fonts.
P.S. Vitaly, in the future, please don't mislead me by telling that you have ran all tests after modification of code and that everything worked fine during the tests, in case if you did not run all of them but those that you thought had been affected.

 

EMF file renders black. [PDF Creator Pilot 289]

Eugene Starkov: 10-23-2007 09:12
Here you are, an EMF file that during conversion turns into the famous "Black Square" of Malevich.

 

Subject: A strange TIFF file [PDF Creator Pilot 287]

Vitaly Shibaev: 01-14-08 09:52
Looks like it is a dead-end. If we embed it "as is", Acrobat does not show the TIFF. Neither Adobe Creator supports that format.
There is no documentation on that subject. It is absolutely unclear what we should do. Let us delay it for an undefined time.

Sergius Bobrovsky: 10-21-07 12:05
CxImage does not read such files. Neither does LibTiff. I failed to find any information about this format - so it is not quite clear what to do.

Eugene Starkov: 10-19-2007 05:48
TIFF file that I attach has a strange compression flag (Jpeg v5). Neither viewer inside Windows nor ACDsee understand that format. Some other viewers, such as Irfan View, FastStone and more, successfully decipher that TIFF and show it.
CxImage seems to understand TIFFs with the JPEG compression, but the library refuses to add such images.
Please take a look. If it wouldn't take too much, it would be wise to support such files since they are not a rare case nowdays. If it would take a lot of time and efforts, don't...

 

A problem with colorspaces [PDF Creator Pilot 286]

Eugene Starkov: 11-06-07 11:49
When the first file is rendered above the watermark, everything is OK. However, if we render two EMF0-files in a row, without any watermarks, Adobe Reader starts to complain again.
Cf. test2.zip

Eugene Starkov: 10-23-07 03:31
Great! Thanks!

Eugene Starkov: 10-18-2007 08:48
If we play on this PDF page two EMF files in a row (both have come from the printer), the Reader starts to complain about a problem with color spaces, and shows nothing.
In the sample, the first EMF is rendered above a watermark. If we render it straight onto the page, it still has some glitches, different ones.

 

Watermarks [PDF Creator Pilot 285]

Eugene Starkov: 10-17-07 10:18
Thanks!

Eugene Starkov: 10-17-2007 03:34
If we create a new document without "killing" the interface, the first CreateWatermark in the new document returns 0, though the PDFPAGE_Watermark property is said to -1 (= no watermarks in the document). Sample attached.

 

The library crashes when used from ASP [PDF Creator Pilot 281]

Sergius Bobrovsky: 10-24-07 00:44
I can tell from scratch that "HPDF_MemStream_FreeData gets called immediately" isn't correct. The stream may have been created earlier, and it must be cleaned before reuse. Cleaning a stream after its creation would do no harm any way.

Vitaly Shibaev: 10-23-07 13:08
Now about the failure. The failure happens when the flag m_bGenerateDocumentInMemory is set to true, and manifests itself as problems inside writeDocumentToMemory().

Detailed investigation revealed 2 problems:
1) In PDFDocumentImpl::SaveToStream, after creation of a pdf->stream and in some other cases, immediately gets called HPDF_MemStream_FreeData, and that is strange by itself. As a consequence, even the first attempt to write anything into the stream results in Access Violation. Let's try to comment the line with HPDF_MemStream_FreeData.
2) When that line is commented, calling HPDF_REadFromStream() from CBinaryBuffer::GetData() results in an error, because of "if (m_Position >= m_Size) return 0;" in MemoryFile::Read(). If replace "return 0" with "m_Position = 0", everything starts to work fine.

Conclusion: we need to review codes of MemoryFile and MemoryStream.
Do we really need CBinaryBuffer?
I won't comment these changes for now, since MemoryFile::Read() is used from several other locations in the code. It is up to Sergey to decide whether that modification would be correct.

Vitaly Shibaev: 10-23-07 12:51
To debug the library when it is used from ASP (Thanks to Stas for the solution), the code from ClassicASPAttachMacro.txt must be placed into a macro of the Visual Studio. Then we should open our library in the VS, and then launch the script that we plan to test in the browser. Then, while the browser is open, we run that macro, and attach to the proper process. After refresh in the browser we get to the proper breakpoint.

Sergius Bobrovsky: 10-08-07 07:02
Most probably, something goes wrong in either exceptions or in the temporary files. Vitaly, did you change anything around them?
Everything worked fine quite recently.

Eugene Starkov: 10-08-2007 06:46
When used from ASP, the library crashes somewhere in EndDoc().

 

MetafileImagesCompressionType [PDF Creator Pilot 280]

Sergius Bobrovsky: 10-08-07 07:36
It is right what I tell: it was a mistake to invent this.

Eugene Starkov: 10-08-07 07:31
This option has been invented right for this: so that users could specify image compression from EMF.
Thanks!

Sergius Bobrovsky: 10-08-07 07:27
This failure is the result of a wrong practice. It certainly was a mistake to provide the users with an option to specify image formats inside PDF.
We must decide: either the user should be able to specify a format (and fight with consequences of his own decision on his own), or the user should not have that opportunity.
Fixed.

Eugene Starkov: 10-08-2007 06:43
In the sample that's attached, if we set MetafileImagesCompressionType to itcJpeg, the image inserts as an empty frame.

 

Subject: One more killer-EMF [PDF Creator Pilot 278]

Sergius Bobrovsky: 10-12-07 05:05
Have you added that to the test case?

Vitaly Shibaev: 10-12-07 05:02
We save (preliminary) temporary Acrobat files (in EMF2ChipConverter::CreateAndSaveFontFile) at our own location. To save the files we use selection on the file names that contain a dot. In the meantime, m_FontIsTemporary in Chip2PDFConverter is set to true if the name ends in ".tmp". This is the reason of the problem. One of fonts in EMF contains a dot in its name. This has been fixed, now EMF2ChipConverter::CreateAndSaveFontFile checks whether a name ends in ".tmp".

Eugene Starkov: 10-10-07 02:10
Vitaly, please take a look , when you will have some time!

Sergius Bobrovsky: 10-08-07 00:27
There is an error in implementation of CLogFontWrapper. When it is created, the name of the font gets copied into a variable that is 32 bytes long. Debugger reveals the problem immediately.

Eugene Starkov: 10-07-07 22:41
It's a megaglitch. I fail to attach the file. I tried 5 times! Download it from here: [link]

Sergius Bobrovsky: 10-07-07 22:11
Where is the file?

Eugene Starkov: 10-05-2007 05:32
This EMF-file crashes converter. Of course, most of the fonts used in the EMF are absent. But it should not crash anyway! :)

 

Subject: Preflight PDF/A [PDF Creator Pilot 277]

Eugene Starkov: 10-09-07 10:13
Great, thanks!!!

Sergius Bobrovsky: 10-09-07 01:51
It was my fault. I created a color profile not quite correctly. Acrobat indicated that it was correct. However, it lead to failures when I attempted to check it.

Sergius Bobrovsky: 10-08-07 07:14
Unfortunately, all "C"s are Roman, I have checked.

Eugene Starkov: 10-08-07 07:08
Isn't any of these "C"s in Cyrillic instead of Roman?

Sergius Bobrovsky: 10-08-07 07:04
Still can't understand why two sequences of absolutely correct commands result in either failure in parsing or crash of Acrobat.

Eugene Starkov: 10-08-07 00:42
Have you ever seen such constructions in the real life? Is it possible to recreate it with some other tools? There may be some hint how to use these strange commands.

Sergius Bobrovsky: 10-08-07 00:17
Investigation shows that this failure happens with both, PDF files generated from EMF and not generated from it.
Below is the script that creates a file that crashes Acrobat, too:
Set PDF = CreateObject("PDFCreatorPilot3.PDFDocument3")
PDF.StartEngine "demo@demo", "demo"

PDF.AutoLaunch = true
PDF.FileName = "HelloPDF.pdf"
PDF.BeginDoc

profile = PDF.LoadICCProfile("sRGB Color Space Profile.icm")
PDF.PDFPAGE_SetColorSpace profile

PDF.PDFPAGE_TextOut 10, 20, 0, "HELLO, PDF!"

PDF.EndDoc
Set PDF = Nothing

Acrobat crashes when there is a construction like this:
/C1 CS
/C1 cs

where the first string installs color profile C1 for lines, the second installs it for fill. This construction is absolutely correct, but Acrobat fails to understand it for unknown reason. If we add color setup, in the other words, add to the output file a construction like this:
/C1 CS
0 0 0 SCN
/C1 cs

then Acrobat does not crash any more, just complains that it cannot parse content of the page any more. Again. this construction is absolutely correct.
What to do? No idea...

Sergius Bobrovsky: 10-05-07 09:12
It has been discovered that this depends on content of a page. Now I see how to debug it, I will try to figure out what to do.
Preliminary diagnose: we violate requirements of the PDF 1.3 specifications (for instance, nesting level of stack operations have some limit) if that's the reason, it will be very hard to correct.

Vitaly Shibaev: 10-05-07 04:36
Acrobat 8 crashes on that check since long ago, for all PDF-files converted from EMF. Sergey was the first to notice that. I still have no idea about what is going wrong there. Sergey, what do you think about it?

Eugene Starkov: 10-05-2007 03:57
For an unknown reason, Acrobat 8 started to crash while checking our PDF files or compatibility with PDF/A. The problem does not depend on fonts embedding. Some other reason...
Vitaly, try to help!

 

Text color gets lost [PDF Creator Pilot 272]

Sergius Bobrovsky: 10-09-07 11:27
Yes, for now.

Eugene Starkov: 10-09-07 11:24
Is it lethal?

Sergius Bobrovsky: 10-09-07 11:05
As usual: tricky superposition of several images.

Eugene Starkov: 10-09-07 10:21
Have anybody tried to figure out what is wrong?

Eugene Starkov: 10-04-2007 07:21
Text color gets lost during conversion of an EMF-file. File has been created by printing from Adobe Acrobat.

 

Subject: Edit box [PDF Creator Pilot 269]

Eugene Starkov: 10-04-07 10:48
Ok, thanks!

Sergius Bobrovsky: 10-04-07 10:45
Ok, let us mark that bug as "fixed" - fonts, glyphs, colors etc work fine, while exact positioning (+/- a pixel) is hardly achievable.

Vitaly Shibaev: 10-04-07 09:39
Now, in case of EMBED_USED_GLYPHS_ONLY the array of widths gets filled completely. It causes no harm. Edit boxes now work fine. Before, in case of glyphs, they did render incorrectly.

Vitaly Shibaev: 10-04-07 09:04
Now I will fill it...

Vitaly Shibaev: 10-04-07 09:03
I have corrected the widths case. I found that in case of EMBED_FULL_FONT the code selected glyphs. Now widths are written correctly, depending on embedding mode. Now they are rendered fine in edit boxes, too. One thing is strange. When the mode is EMBED_USED_GLYPHS_ONLY, glyphs are selected, and their own widths are written - but everything draws fine.

Sergius Bobrovsky: 10-04-07 08:55
Vitaly, to confirm my claim about the font widths, try to type "Hide e-mail" (without quotes) - nothing gets collapsed.
Eugen, it is impossible to make it fit exactly anyway. Acrobat calculates its text rendering on its own. I tried myself to adjust it, and it did not help. After a click, Acrobat draws everything on its own, all I can do is to control the font, size and color of the text. It is impossible to control positioning and anything like that. If we zoom the screen, we may notice that characters shift not only in the horizontal direction, but vertically, too. That may be a glitch of antialiasing.

Eugene Starkov: 10-04-07 08:06
Vertical alignment against center should be good for one line Edit boxes. Is it possible to predefine central alignment for one-line Edit boxes and top alignment - for the multi-line ones?

Eugene Starkov: 10-04-07 08:04
"I will correct that (vertical alignment against center instead of against top) if needed" - Please, correct it!

Sergius Bobrovsky: 10-04-07 07:57
Well,the same answer to all questions:
Vertical alignment works this way by design, it was ported from the code of Stas. I will correct that, if needed.
Cursor fails to offset horizontally because some people fail to specify widths for an inserted font.

Eugene Starkov: 10-04-07 05:33
One more bug: on opening a document, if there isn't a lot of lines, these lines become aligned vertically against the center of the page, while they must align against its top. When anything is entered in the field, everything normalizes. The text starts to align against top (properly).

Vitaly Shibaev: 10-04-07 05:14
It can bee seen in RegisterForm.vbs.

Sergius Bobrovsky: 10-04-07 02:24
Fixed.

Eugene Starkov: 10-03-07 22:38
One more bug, most probably related to the first one. Look at <more.zip>.
Immediately after opening a PDF-document, the first field shows only the first string, and renders it in bold and italic. The same happens in the second field (bold and italic are NOT set). After a click in any of these fields, all text reappears. When the focus moves to another field, there is again only the first string in this field. If we enter some data into the fields, strings stop to disappear; however, the first field loses its bold and italic styles.

Eugene Starkov: 10-03-2007 03:46
It is impossible to set up the fill color inside Edit boxes. The Text color mutates in a strange way. When the box is focused, this color is correct. When it is not focused, the color is wrong.

 

GIF [PDF Creator Pilot 256]

Eugene Starkov: 10-01-07 23:02
Muchas gracias, señor!

Sergius Bobrovsky: 10-01-07 22:54
I have fixed this bug.
By the way, we might advise the users to use AddImageFromFile(), in which they don't need to specify the type of compression. It will choose an appropriate type of compression by itself.
The only case when AddImageFromFileName() should be used is when the user wants to convert a color image into a BW (in this case one must specify itcCCIT3, itcCCITT32d or itcCCITT4).

Eugene Starkov: 10-01-2007 12:23
The library does not want to render GIFs, I suspect this problem is related to transparence, since GIFs with no transparency are inserted fine.

 

A sample in Delphi [PDF Creator Pilot 0000234]

Eugene Starkov: 09-28-07 02:11
Thanks!

Sergius Bobrovsky: 09-28-07 02:00
I've replaced it. I could not check it myself since I don't have a copy of Delphi.

Eugene Starkov: 09-28-2007 01:32
Sergey, please replace the Delphi sample in the library (look at the attachment).

 

Rotation angles [PDF Creator Pilot 233]

Vitaly Shibaev: 10-30-07 13:48
I have refreshed the documentation.

Vitaly Shibaev: 10-01-07 07:31
Yes, let us hold it with the status of "Information".

Eugene Starkov: 10-01-07 04:35
Most likley, it did not convert properly in 3.6.366, too. The user must have mixed up the screenshots., while I have checked it with the latest version only.
I think we will not close this ticket until the docs get corrected?

Vitaly Shibaev: 09-28-07 05:29
Fixed. It was a result of ambiguity of the documentation. Long ago, when the graphic mode had been re-factored, (when there were some problems with the arcs), there was no good test to check back compatibility for RectRotated. It was unclear how that call was intended to work, what requirements should be requested for its parameters etc. As a result, after re-factoring, it was presumed that rendering starts from the lower left of the image, clockwise. Why I presumed this, I don't know.
When documentation will be updated, we need to make parameters more systematic (in PDFDocument and PDFPage).
By the way, it's a wonder how the library could convert this code earlier. I have rolled the library back to the 366th revision, and tried: it converts in the same way as the new ones.

Sergius Bobrovsky: 09-28-07 02:07
It is a bug, certainly.

Eugene Starkov: 09-28-2007 01:29
In the latest versions of the library, rotation angles in PDFPAGE_RectRotate are processed differently from the earlier versions. There are two samples in the attachment, from v 2.5 and v 3.6.366.
Version 3.6.423 rotates shapes in the opposite direction. Is it a bug or a feature?

 

Subject: Inherit security from folder [PDF Creator Pilot 232]

Eugene Starkov: 09-28-07 01:34
Well. I agree.

Vitaly Shibaev: 09-28-07 01:27
I agree, the problem is not related to the library.

Sergius Bobrovsky: 09-28-07 01:20
Eugine, are you sure it is a problem of the library? The library creates files with default settings, all rights are granted by Windows, and I think it is OK.

Eugene Starkov: 09-28-2007 01:13
Users ask that the generated PDF file inherited security settings from the folder where they belong. Most likely, we must look at the API function SetSecurityInfo(). I have also found this: http://support.microsoft.com/kb/266461.
It is in basic, however it must give us information about proper initializations and so on.

 

COM Exceptions [PDF Creator Pilot 231]

Sergius Bobrovsky: 10-08-07 07:01
I agree that it would have been great, but now it is too late. Implementation of that interface was never planned, and now I don't think it would have a sense.

Eugene Starkov: 09-24-2007 03:21
It would be great to supply library exceptions with comprehensible text comments. Here is a sample of how that can be done with a help of IErrorInfo: http://msdn2.microsoft.com/en-us/library/ms221186.aspx

 

EnhancedMetafile.vbs [PDF Creator Pilot 0000217]

Eugene Starkov: 09-21-07 03:44
Thanks!

Eugene Starkov: 09-21-2007 01:37
One of library samples does not work correctly. That must be fixed before the next release.

 

Superscript text [PDF Creator Pilot 208]

Sergius Bobrovsky: 09-10-07 17:38
This error shares its nature with that described in #203. Output has been optimized in the same way: the pluses and the 'x's are rendered with an increased distance between characters.

Eugene Starkov: 09-10-2007 11:11
Problems with superscript text and the '+' characters.

 

Vanishing lines [PDF Creator Pilot 207]

Eugene Starkov: 09-21-07 01:38
Thanks!

Sergius Bobrovsky: 09-17-07 11:54
There was an error, but it was related with libharu streams, not with watermarks. The script just made that problem visible. Now this error does not appear any more, the page looks alright amd all lines render.
Don't give that to the clients, since it is not yet tested, and Vitaly works hard with the fonts :)

Eugene Starkov: 09-13-07 10:40
We have removed everything unneded from the script (see new.zip) Script is correct, however the problem is still there.
When we switch off the watermark ('PDF.PDFPAGE_Watermark=0), all lines start to render.
When the watermark is on, some error is reported and some lines stop to render.

Sergius Bobrovsky: 09-10-07 08:14
There is a fragment like below in the attached script:
PDF.AddImageFromFilename
"C:\DOCUME~1\Vladimir\LOCALS~1\Temp\anf_temp\bgnd_img.jpg", 1
PDF.PDFPAGE_ShowImage 0, 0.000000, 0.000000, 612.000000, 842.250000,
0.000000
PDF.SwitchedToWatermark=false
PDF.PDFPAGE_Watermark=0
When we comment this line out:
PDF.PDFPAGE_Watermark = 0,
everything works fine, the lines start to render.
The script indicates that after the watermark has been switched off, it was switched on again. That was the reason for the problem.
Another question: why it's me who checks that, not Stas?

Eugene Starkov: 09-10-2007 06:03
In a document half of its lines... disappear. See attached script and Untitled1.pdf.
Opening that file, Adobe Reader 7 complains about an unrecognized token (see screenshot). Adobe Acrobat 8 does not complain, and does not draw.

 

Vector problems [PDF Creator Pilot 205]

Sergius Bobrovsky: 09-10-07 04:13
There is no surface concept in PDF. Most of operations that mix the things already rendered with the things that are about to get rendered, cannot be transfered directly from GDI into PDF
There is a variant with preliminary calculations inside converter, but it is close to writing our own GDI driver. Because of complexity and low demand, I don't think it is worth trying.

Eugene Starkov: 09-10-07 00:14
Tell me please, is it absolutely impossible to do with PDF API, or we just have to do a lot of extra work?

Sergius Bobrovsky: 09-09-07 17:34
We can't.
It is not a problem with vectors. Vectors draw ok. The problem is that images that are rendered by StretchDiBits, with the flag SRCINVERT do not render correctly in a PDF.
The worst about this: it seem to never become possible. I don't think that this feature of GDI may be transferred into PDF in any adequate way.

Eugene Starkov: 09-09-2007 12:57
Can we convert shapes like this? (see attachment)

 

Stretched characters [PDF Creator Pilot 204]

Sergius Bobrovsky: 09-09-07 17:30
Fixed, look at the SVN.

Eugene Starkov: 09-09-2007 12:40
During conversion of the attached file, we observe vertical stretch of characters.

 

Subject: Formatting gets lost [PDF Creator Pilot 203]

Eugene Starkov: 09-10-07 00:10
They tell that they printed out a PDF file. It must be Acrobat Reader or its kinsmen.

Sergius Bobrovsky: 09-09-07 13:01
By the way, what a super-program produced this file?

Sergius Bobrovsky: 09-09-07 13:01
This error shares the same nature with error that was described in the #14.
The very gist of it: strings are transfered exactly as they are rendered inside PDF. Spaces (word breaks) appear because there is an arrays of inter-character distances. At positions with 3 times larger space between characters than anywhere else, one can visually observe bigger distances between the rendered characters.
It is possible to correct that error by breaking an input string into several separate strings, and then output them sequentially. However, since it is not an universal approach and it may be killing for productivity of converter, I would not suggest to go this way.

Eugene Starkov: 09-09-2007 12:37
During conversion of the attached EMF, text formatting gets lost.

 

Subject: Bembo font [PDF Creator Pilot 202]

Eugene Starkov: 09-21-07 01:38
Excellent!

Vitaly Shibaev: 09-14-07 15:42
Fixed. There is now a pseudo-unicode output for Type1 fonts, and it works.

Eugene Starkov: 09-14-07 08:16
The user understood that this font is commercial, and that we won't embed it. However, we have to investigate the case when a Type1 font gets embedded, while not used.

Vitaly Shibaev: 09-12-07 12:59
The TTF font from the attach is a commercial one (fsType = 2). It is still obscure for me, why the Type1 font gets embedded instead of it. However, it is clear why a Type1 font gets replaced with Arial: it is impossible to use a Type1 font with Unicode.
Verdict: it is impossible to output Unicode text in that font because the font is commercial.

Eugene Starkov: 09-09-2007 12:21
Another mysterious font. In a converted PDF it is always replaced with Arial.
There are TTF and Type1 versions of that font in the archive. I tried to install only TTF. Upon that installation, the font gets replaced any way.
Then I additionally install the Type1 version, the font still gets replaced, now with a glitch: PDF embeds the Type1 version, while uses the TTF one.

 

Unused fonts should not get into the final documents [PDF Creator Pilot 0000201]

Sergius Bobrovsky: 09-14-07 19:11
Files always contain Helvetica, even if there is not a single string of text. The worst: test TestFontEmbedding (that I have added today) returns something impossible to imagine.
Implementation seems to be lame any way.

Sergius Bobrovsky: 09-04-2007 08:24
Now there is a lot of unused fonts in the output documents. Say, a user selects Arial, then [s]he immediately selects Times, and outputs a string of text. The document will contain both, Arial and Times. There must be only Times.

 

One more EMF with problems [PDF Creator Pilot 193]

Eugene Starkov: 08-22-2007 06:57
After conversion, all space between columns of the diagram gets filled with black.

 

Insignificant problems with kerning [PDF Creator Pilot 185]

Eugene Starkov: 08-20-2007 06:37
During conversion of the attached EMF-file, text in some cells gets stretched horizontally. For instance, text "182d" after conversion looks as if there was a space before the "d".

 

Embedding of Base-14 fonts [PDF Creator Pilot 177]

Vitaly Shibaev: 07-31-07 06:45
Ok, I am doing that.

Sergius Bobrovsky: 07-31-2007 05:49
It is necessary to add embedding of Base-14 fonts (Helvetica and alike), to comply with the requirements of PDF-A.

 

Tag OutputIntents isn't written into output documents [PDF Creator Pilot 176]

Sergius Bobrovsky: 08-27-07 18:53
New methods description has been added. A tedious work!!!

Sergius Bobrovsky: 08-26-07 19:47
In general, I have finished support of color spaces, Clip Document has changed, too. A pair of tags that have been just announced now do exist and work.

Now, to the list of supported standards
DeviceGray
DeviceRGB
DeviceCMYK

we have added two new ones:
ICCBasedRGB
ICCBasedCMYK

It is good for the PDF/A, it is also good for those who needs exact color synchronization. I have written several tests to check how that works, and I have attached here results of one of them. An amazing effect: there are four squares, all of then rendered in the same color, but they look somewhat different. Near every square there is the name of the color space with which it was rendered.
I have also added support of color spaces into EMF (and in the virtual context, too). It is possible to generate a file like the attached one with the help of TestEMFColorspaces. For CMYK color spaces, see TestCMYKColorspaces.
All we have to do now is to describe the new methods in the documentation, and close the ticket. Then I will bring together everything what is needed for support of PDF/A, and after Vitaly comes back we will check everything and release a new version.

Sergius Bobrovsky: 08-17-07 12:06
OutputIntents has been added.
To add this tag I had to implement (almost completely) all operations with the color spaces. It is not nuclear physics, but initially I knew nothing in that area. Now I decided to finish color spaces, too.

Sergius Bobrovsky: 07-31-2007 05:47
Optional tag OutputIntents isn't written into the catalog of the output documents.
That tag is needed to pass the PDF-A compliance validation.

 

Tag MarkInfo isn't written into the output document [PDF Creator Pilot 175]

Sergius Bobrovsky: 08-02-07 03:20
Now this tag is written, with default values. There are no other - our documents are not logically structured.

Sergius Bobrovsky: 07-31-2007 05:34
We need to write optional tag MarkInfo into the catalog of the output document. Otherwise the document will not pass the PDF/A compliance validation.

 

When a file is created, tag ID isn't written to the trailer [PDF Creator Pilot 174]

Sergius Bobrovsky: 07-31-07 15:29
I have added that tag. The validator started to complain about one position less. ;)

Sergius Bobrovsky: 07-31-2007 05:28
During creation, tag ID isn't written into the trailer. This tag is marked in the PDF Reference as "Optional, but strongly recommended". Without that tag, the document will not be in position to pass the PDF/A compliance validation.

 

Font HolidayPi BT [PDF Creator Pilot 173]

Eugene Starkov: 07-26-07 23:06
Thanks!

Vitaly Shibaev: 07-25-07 12:26
Cool font! I will look at that tomorrow.

Eugene Starkov: 07-25-2007 12:15
A client has sent us a symbol font named "HolidayPi BT".
The library refuses to convert it.
No error is reported, but the PDF file isn't created.
See the attached EMF.

 

ETO_CLIPPED in ExtTextOut [PDF Creator Pilot 0000169]

Sergius Bobrovsky: 04-02-08 11:12
Upon request of Slavomir Korbas :-) I have sped up the process, and added support for ETO_CLIPPED. Now the text gets cut as it should. After testing this a little, I noticed that it seems to work.
I did not test it thoroughly, though.
We could give the clients our intermediate build, with a note that is it not quite tested... or maybe, we would better test it ourselves.

Eugene Starkov: 06-21-2007 04:26
The library ignores the ETO_CLIPPED parameter in ExtTextOut.

 

Requested a function of text output with pagination [PDF Creator Pilot 0000162]

Eugene Starkov: 09-25-07 11:50
No, that function IS needed. It must look approximately like this: int PlainText(BSTR text, LONG leftMargin, LONG topmargin, LONG rightMargin, LONG bottomMargin);
It must return the number of resulting pages.

Sergius Bobrovsky: 09-21-07 23:47
Three months have passed, but I still don't know for sure what is needed.
Or nothing is needed - if so, let us close the ticket.

Sergius Bobrovsky: 06-17-07 02:15
Eugin, please write in more details how these functions should work.
What should they get from the user, how should they behave.
In general it is more or less clear, but just in general.

Eugene Starkov: 06-01-2007 09:43
A function is needed for automatic output of text with pagination, and user-specified margins.

 

Documentation Update [PDF Creator Pilot 161]

Eugene Starkov: 10-17-07 12:37
It's normal :)

Vitaly Shibaev: 10-17-07 12:31
My fault: I did not update Tests.cpp after I had changed the order in which the tests are executed. And I don't know how I managed to never notice these problems: I rebuilt it twice before commit...

Eugene Starkov: 10-17-07 09:59
Tests.cpp and StaticTests.cpp complain about PDFPAGE_ArcTo.

Sergius Bobrovsky: 08-28-07 18:21
Vitaly, please do that yourself!

Vitaly Shibaev: 06-01-2007 09:19
It is necessary to update documentation and rename parameters in the interface of PDFDocument for both, static and COM, versions.
1) Method parameters of PDFPAGE_Arc are (DOUBLE cxLeft, DOUBLE cyTop, DOUBLE cxRight, DOUBLE cyBottom, DOUBLE cxFirst, DOUBLE cyFirst, DOUBLE cxSecond, DOUBLE cySecond, DOUBLE* cxCurrent, DOUBLE* cyCurrent)

2) Method parameters of PDFPAGE_Arc2 are (DOUBLE cxCenter, DOUBLE cyCenter, DOUBLE dxRadius, DOUBLE dyRadius, DOUBLE dDegreeStartAngle, DOUBLE dDegreeSweepAngle, DOUBLE* cxCurrent, DOUBLE* cyCurrent). Text regarding current (not final) sweep angle needs to be changed, too

3) Method parameters of PDFPAGE_Pie are (DOUBLE cxLeft, DOUBLE cyTop, DOUBLE cxRight, DOUBLE cyBottom, DOUBLE cxFirst, DOUBLE cyFirst, DOUBLE cxSecond, DOUBLE cySecond). Text on drawing direction (that always goes counterclockwise) must be changed.

4) Method parameters of PDFPAGE_Pie2 are (DOUBLE cxCenter, DOUBLE cyCenter, DOUBLE dxRadius, DOUBLE dyRadius, DOUBLE dDegreeStartAngle, DOUBLE dDegreeSweepAngle). Text regarding current (not final) sweep angle needs to be changed. Text on drawing direction (that always goes counterclockwise) must be changed, too.
These were the most important changes. There is also an undocumented method PDFPAGE_ArcTo, with two additional parameters placed before blsClockwise: cxCurrent and cyCurrent. Being identical to PDFPAGE_Arc it allows to specify the drawing direction. It is utterly important for the converter. It would be nice to add its description, too - though it is not that important.

 

I suspect that a part of the document isn't released during call of EndDoc [PDF Creator Pilot 00000154]

Sergius Bobrovsky: 01-08-08 22:49
Now there are no suspects in leaking or non-releasing the memory. :-)

Sergius Bobrovsky: 05-22-2007 13:40
I suspect that a part of the document isn't released during call of EndDoc. When I call Release, everything gets released.
It may lead to increase amount of the used memory (though, as far as I understand, there is no leak).

 

Feature request: Render a long EMF file to multiple pages [PDF Creator Pilot 0000090]

Eugene Starkov: 09-25-07 11:42
Well, let's close this ticket.

Sergius Bobrovsky: 09-21-07 23:45
Is that feature demanded? Nobody else asks for that.

Eugene Starkov: 02-16-07 00:18
No, it is not a case of custom development. It would be a great feature. Complaints - it is another topic. It is always possible to complain about anything...

Sergius Bobrovsky: 02-15-07 01:00
It is absolutely real, for sure. It's done in HTML2PDF Add-on. But... Then there will be questions about quality of split of the pages, for instance "why this picture gets cut while texts don't".

Eugene Starkov: 02-14-07 22:14
First tell me, whether it is doable or not. Maybe it would be better to just say "no"?

Sergius Bobrovsky: 02-14-07 05:51
A question: could we ask that user to pay us for that service? It is outside of the product's specifications. It looks like custom development.

Eugene Starkov: 02-06-2007 10:12
We should implement pagination of large EMF files into multiple pages, like it is done in the add-on.

 

Feature request: ISO PDF/A [PDF Creator Pilot 088]

Sergius Bobrovsky: 01-08-08 22:45
Since there was no complaint during 4 moths, we may close that topic.

Sergius Bobrovsky: 08-28-07 18:27
To support PDF/A, I have added the following functions to the library:
LoadICCProfile
SetPDFAOutputIntent
SetPDFXOutputIntent

PDFPAGE_GetColorSpace
PDFPAGE_GetColorSpaceType
PDFPAGE_SetColorSpace
PDFPAGE_SetDefaultGrayColorSpace
PDFPAGE_SetDefaultRGBColorSpace
PDFPAGE_SetDefaultCMYKColorSpace

PDFPAGE_SetColor
PDFPAGE_SetColorFill
PDFPAGE_SetColorStroke
I have added this property:
ProducePDFA

and that new data type:
TxColorSpaceType

I have described all of that in the documentation, made changes in the library code to make everything work.
Now I regard implementation of PDF/A as finished, when Vitaly is back we will test that.
Eugene, please test it, too - if you can. A test is named TestPDFA.

Sergius Bobrovsky: 08-02-07 17:15
We continue to ascend to the glorious future: I mean support of PDF/ A-1b (basic).
By this moment, I made it possible to store XMP Metadata (in formats PDFAID, Adobe PDF and XMP Basic), and then I commented that code out.
I commented it out because there are no tests to check output format for compliance with PDF/A-1b and no control. To comply with PDF/A-1b format must be not lower than PDF 1.4.
Remains to be done:
1. Embedding of Base-14 fonts
2. Probably, embedding of Type1 fonts
3. Correct embedding of all other fonts (there are some complaints about encodings)
4. Embedding of rendering intents, although some validators don't complain when they are missing
5. Implementation of a mechanism to switch PDF/A-1b on and off, and ways to support generation of a special PDF document (ignoring compression, cryptography etc).

Sergius Bobrovsky: 05-24-07 14:29
OK, but not in this release. This feature will require a lot of work, and there will be no time to properly test it. We've fixed a lot of bugs, and we must release the new version now.

Eugene Starkov: 05-24-07 06:57
Let us do the basic level, then?

Sergius Bobrovsky: 05-23-07 20:58
Well, it appears to be not that easy. There are two levels of conformance to the PDF/A standard: normal and basic. We may implement now only the basic level. We are not in position to conform to the normal level because we have no way to create Tagged PDFs (it is one of the reasons).
In short, a Tagged PDF is a PDF with contents organized as a logical structure. It means, among the other things, that there may be no random positioning of the text (it is impossible to render the last word of a sentence first, and then the other words). Words don't split into characters, instead they are used as words. The order of text rendering in a PDF stream is the same as the order of screen rendering and reading direction.
As a minimum, we must define paragraphs and headers. And so on.
A lot of work and no way to generate a Tagged PDF by converting EMF files. I don't know what to do.

Sergius Bobrovsky: 05-07-07 08:39
Today I will finish with the images (hopefully), and then I will delve into this. I planned to implement this and printer context selection before the new version. Then we will write the press-release.

Eugene Starkov: 05-07-07 08:36
Again they're asking about PDF/A. I think it is the time to implement it...

Eugene Starkov: 02-01-2007 11:50
We use PDF Creator Pilot 3.0 with Image2PDF 1.3 and Html2PDF Add-on 3.3.
Could you please provide us with the information how to create an ISO PDF/A compatible file or, if this may not be possible at the moment, please give us an estimation when this feature will be available in your API.

 

PDFPAGE_TextOut does not always work fine [PDF Creator Pilot 079]

Vitaly Shibaev: 10-24-2007 10:27
During some additional tests, I have discovered that PDFPage::SetPixel fails to work correctly at (0, 0). Further investigations showed that while m_InternalSize of PDFPage was initialized with floating point data, like (595.276, 841.89), the / MediaBox clause inside PDF file uses integers. Now this problem has been fixed and PDFPage::SetPixel works OK.

Sergius Bobrovsky: 11-29-2006 10:37
After calling PDF->PDFPAGE_TextOut(0, 0, 0, "abcdefgABCDEFG12345!#$%&+-@?"); part of the string is inserted outside of the page boundaries. It seems that the height of the string is calculated based on the first character, not on the character with the largest height.

 

WordArt objects convert incorrectly [PDF Creator Pilot 059]

Sergius Bobrovsky: 07-02-07 19:07
See comment to error #0054.

Eugene Starkov: 10-19-2006 19:47
WordArt objects don't convert right. See the sample in attachment.

 

An EMF file converts wrong [PDF Creator Pilot 0000054]

Sergius Bobrovsky: 07-26-07 12:17
Max, the bugs that you have added to the list, must be observed.
If you put status "Solved", you have to check whether the problem has actually been solved. If it is, just close the ticket. If not - write about it!

Sergius Bobrovsky: 07-02-07 19:06
There were problems with both, clipping paths and PolyPolygon processing. Both have been fixed.

Sergius Bobrovsky: 10-05-06 22:20
It has been discovered, that conversion failed to take in account the "clipping path" for images rendered in the topmost layer above the text. I have added basic support for such paths, and even the last character started to convert right. However, support of such paths in the library looks like unfinished. This code isn't stable. In particular, even samples don't work.
I will send Stas a bug-report.

Maxim Filimonov: 10-05-2006 14:32
Attached EMF-file converts absolutely wrong.
I call m_PDF->PDFPAGE_PlayMetaFileExFromFileName(fName, 0, 0, 1, 1);

 

The library does not support pattern fills [PDF Creator Pilot 013]

Sergius Bobrovsky: 09-18-2006 15:52
The library does not support pattern fills. See PDF Reference (4.6 Patterns).
It is a very useful feature, notwithstanding it is rarely implemented so far.

 

The library does not work correctly under Windows 98 [PDF Creator Pilot 010]

Sergius Bobrovsky: 09-21-07 23:44
I think we should stop supporting Windows 98 (and NT 4, too), since no-one asked a question about them for at least a year.

Sergius Bobrovsky: 09-18-2006 15:43
The library seamlessly and correctly installs and registers in Windows98 (I tried it under Windows 98 SE Rus), test application converts its EMF-file, then Acrobat refuses to open the result, complaining that it misses something, and then - that the file is corrupted beyond repair.
I think it happens because of objects, inserted into PDF.

 

Probably, the library fails to work correctly under Windows NT4 [PDF Creator Pilot 009]

Eugene Starkov: 09-25-07 11:51
Yes, I think we can do that with an easy mind.

Sergius Bobrovsky: 09-21-07 23:43
I think we should stop supporting Windows 98 (and NT 4, too), since no-one asked a question about them for at least a year.

Sergius Bobrovsky: 09-18-2006 15:41
The library refuses to work under Windows NT 4 unless there is Internet Explorer 4.0 installed.
Earlier the library did not work under Windows NT 4 because it used GetLongPathName, but now that problem seems to be fixed. It is impossible to tell for sure, whether it works correctly with NT4 or not. A test is needed.