Just installed 5.19.3, and noticed that the last image in a heading does not align properly. If the image is "position as character", the last linked image inserted into a header gets aligned really high. Add another image, then that previous image is now aligned properly, but the new image is now aligned high. This was fine in 5.19.1.
WPTools 5.19.3
Delphi 7
It appears that the default date used for Info.Date and Info.ModDate for wpdfExport 2.61 is not correct.
When viewed by Acrobat 7.0.5, the dates are coverted to local time. So if I really created a PDF doc at 12pm my local time (GMT-7), Acrobat shows the creation and modified time as 5am. Not sure where the time is converted... at the reader end or at the creation end.
If I convert local time to UTC time and set the Date and ModDate myself using the UTC time, Acrobat displays the time correctly.
function GetUTCTime: TDateTime;var SysTime : TSystemTime;begin GetSystemTime(SysTime); Result := SystemTimeToDateTime(SysTime);end;and
with WPPDFExport1 do
begin
Info.Date := GetUTCTime;
Info.ModDate := Info.Date;
end;Eric
Question... As far as Acrobat Reader 7.0 is concerned, is the font name case sensitive?
Reason I ask is that I've been excluding the Wingdings font from being embedded in the PDF doc for a while now (including WPTools 4). And have had no problems doing that when the Wingdings font is on the destination computer.
Suddenly I noticed that, and I don't know exactly when this started happening, if I view a PDF created with WPTools 5 (5.19.1) and WPPDFExport (2.61), Acrobat cannot find or substitute for "WingDings" (note the upper case "D"). With an older doc created with WPTools 4, it is OK with "Wingdings" (note the lowercase "d"). The font name being referenced was determined based on the font list displayed by Acrobat 7. It is as if the font name is case sensitive.
If I embed the font, it works fine since it is looking for "WingDings" and it is now embedded that way.
While I believe the actual name is "Wingdings" not "WingDings", I still find it hard to believe the font name would be case sensitive, so I'm thinking something else is keeping Acrobat from finding a compatible font.
So, do you know off the top of your head what Acrobat looks for to obtain a suitable font match when the font is not embedded? Maybe I've screwed up the charset value or something.
Thanks,
Eric
Good point.
If I set a linked image for text wrap using:
SelectedObject.Wrap := wpwrBoth;
SelectedObject.PositionMode := wpotPar;and then drag the margin left or right, the paragraph adjusts to the new margins, but the image does not. I would have expected that if I move the left margin to the right an inch, the linked image would also move to the right an inch since it is set to be relative to the paragraph not the page.
Is this the correct behavior? If so, do you have a quick and dirty method I can add to my code to manually move the linked image-with-text-wrap when a margin change occurs?
WPTools 5.19.1
D7
Eric
Yes, last_red and last_green was there, but Value=0 was not.
This is what was there:
(last_red=0) and (last_green=0) and (last_red=0) then
Note that last_red was in there twice.
As in your reply, changed it to:
(last_red=0) and (last_green=0) and (Value=0) then
and that fixed it... thanks!
Eric
This is hard to explain, but if a table is indented, the right margins do not restore properly when saved and reloaded.
1. Create several paragraphs, and indent about 1 inch or so.
2. Create a 1x1 table on one of those indented paragraphs
3. Note that the table's left edge does not honor the paragraph's indent (unexpected but not important for this example)
4. Drag left edge of table to the margin we had indented, i.e. 1 inch or so.
5. Place text cursor inside table cell and make a note of the right margin and the table's right margin indicators in the ruler (looks to be about the same position)
6. SaveToFile and restore it via LoadFromFile
7. Place cursor in the table cell once again
8. Note that the right margin has moved left by the indent amount, yet the table right margin indicator is still at the position it should be.
This gets worse if you moved the left edge of the table more than the right margin amount (i.e. if the right margin as half an inch and you then moved the left edge of the table one inch to the right)... example:
1. Create several paragraphs, and indent about 2 inches or so (more than whatever the right margin is... say for example the right margin is 1 inch).
2. Create a 1x1 table on one of those indented paragraphs
3. Note that the table's left edge does not honor the paragraphs indent (unexpected but not important for this example)
4. Drag left edge of table to the margin we had indented, i.e. 2 inches or so.
5. Place text cursor inside table cell and make a note of the right margin and the table's right margin indicators in the ruler (the right margin is at the page right edge, and the table's right margin is off the page... unexpected).
6. Drag the right edge of the table back onto the page and note the right margin and table's right margin indicators on the toolbar (should be about the same)
7. SaveToFile and restore it via LoadFromFile
8. Place cursor in the table cell once again
9. Note that the right margin has moved left by the indent amount, yet the table right margin indicator is still at the position it should be.
Now when you key in text, it wraps at the page margin not the table margin (text only partially fills the cell) because the page margin is not corrrect.
In any event, the save and reload does not produce the table in the state is was before the save.
WPTools 5.19.1
Delphi 7
Eric
If you set the text color to either blue or navy blue using the toolbar, the color reverts back to black when saved and reloaded (SaveToFile, LoadFromFile). Other colors seems to work fine (I didn't check them all however).
WPTools 5.19.1
D7
Eric
OK, I think I understand, but couldn't the toolbar be made so that when the font size is undefined for some text that it show the DefaultAttr font size (or whatever the font size being used in that case) on the toolbar rather than just a blank? Then I won't have to explain to my customers as to why the font size is blank even though they set it to something. Maybe make it yet another option? :D
Couple of odd things when trying to use the TWPSymbolDlg control...
If I invoke the dialog and chose a char from the font shown, it seems to work. However, if I pick a different font from the pulldown, and select a char, it initially displays using the current font, not the selected font. Saving and reloading the WPRichText causes it to dispaly properly.
Note that I do a Refresh after calling Execute, but that does not display it properly... I still have to save and reload.
One other thing... If the text cursor is at the end of the text, the dialog seems to default to the Wingdings font, not the current font. And even if I then pick from that Wingdings font, it initially displays using the current font, not Wingdings (but is OK once I save and reload).
This is the code I use:
procedure AddCharFromCharMap( richText: TWPRichText );
begin
with WPSymbolDlg1 do
begin
EditBox := richText;
if Execute then
richText.Refresh();
end;
end;WPTools 5.19, Delphi 7, WinXP
Thanks,
Eric
If the font size of some text is equal to whatever you set the DefaultAttr font size to, the WPToolBar font size shows as blank when the text cursor is placed on that text.
For example, if you set some text to a font size of 12 when the DefaultAttr is set to 11, then placing the cursor on that text the toolbar font size works fine. Without changing anything else, set the DefaultAttr font size to 12, and reload the text. Now when you place the text on that size 12 text, the toolbar shows a font size of nothing.
WPTools 5.19 and earlier, D7, WinXP
Eric
This still fails in 5.19. Do I need to send an example to help out?
To summarize, if you set the CHARACTER background color to black, it is fine until you SaveToFile and then LoadFromFile. The character color is then no longer black, but reset to white (or neutral perhaps). Setting the character background color to anything but black works fine, and also setting the PARAGRAPH background color to black also works fine.
Background colors are being set using the toolbar.
Thanks for all your other fixes!
Example sent... hope it helps!
Eric
Yes, wpfDontTabToIndentFirst set to true corrects the problem.
You might want to check something though. With that set to the default of false, if the first line indent is not equal to the left margin, i.e. set to the right of the left margin, then the first tab does not line the text up with the hanging indent, and is rather shifted by the first line indent amount. That just seems totally wrong for being a default setting.
Sample:
{\rtf1\ansi\deff0\uc1\ansicpg1252\deftab720{\fonttbl{\f0\fnil\fcharset1 Arial$;CharFontSize:;}{\f1\fnil\fcharset1 Arial;}{\f2\fnil\fcharset1 WingDings;}}{\colortbl\red0\green0\blue0;\red255\green0\blue0;\red0\green128\blue0;\red0\green0\blue255;\red255\green255\blue0;\red255\green0\blue255;\red128\green0\blue128;\red128\green0\blue0;\red0\green255\blue0;\red0\green255\blue255;\red0\green128\blue128;\red0\green0\blue128;\red255\green255\blue255;\red192\green192\blue192;\red128\green128\blue128;\red0\green0\blue0;}\wpprheadfoot1\paperw12240\paperh15840\margl1880\margr1880\margt1440\margb1440\headery720\footery720\endnhere\sectdefaultcl{\*\generator WPTools_5.18;}{\*\userprops {\propname databases}\proptype30{\staticval DATA,LOOP10,LOOP100}
}{\li2835\fi-1701\plain\f1\fs22 2005/10/24\tab In my opinion, with the default settings, this should line up with the hanging indent text shown in the wrapped lines, but it is shifted by the amount of the first line indent.\par
}}Thanks once again for your quick solution!
Eric
If the first line indent differs from the hanging indent (i.e. the first line indent marker is to the left of the hanging indent marker), then the first, and only the first, tabstop to the right of the hanging indent is ignored. Obviously, if the firstline indent is the same as the hanging indent, then the first tabstop is OK.... only when they differ is the first tabstop to the right ignored.
Simple to demonstrate, but I'll send you an example if you want.
WPTools 5.18.8, D7
As usual, this is a rather critical issue! :)
Eric
Seems that FindParWithText is a case sensitive search... would it be possible to add an optional parameter to allow it to ignore case? Or have I missed something (if so, sorry about that).
Thanks,
Eric
If I have a paragraph with the paprNewPage property set, then everytime I save the document, such as with SaveToFile, it adds an additional empty paragraph in front of the paragraph that has the paprNewpage property.
So, when reloading the document, such as with LoadFromFile, and resaving it again with SaveToFile, I then have two empty paragraphs. If I do it a third time, yup, three empty paragraphs, etc etc.
WPTools 5.18.8, Delphi7
I see you added something to be compatible with Word in 5.11.2, i.e. \page\par when writing a paragraph with the paprNewPage attribute, but I don't see how you compensate for that when reloading.
Eric
This is still a problem in 5.18.8. I will send you an example using your coloring the paragraph technique. You can see the problem by looking at the RTF, but this is more visual.
The keep attribute saves-to-file and loads-from-file fine, but once you add a KeepN to the same paragraph, and SaveToFile, the keep is lost... only the keepN remains.
Eric
P.S. Even though this seems to be a problem, I am having a hard time trying to think why you would even need the keep attrib if you have the keepN anyway... other than to simply retain the keep should you remove the keepN later. I think a keepN encompases what a keep does, but not the other way around.
I replaced FastAppendText with the following routine, and it appears to take care of it, but it would have been nice if FastAppendText kept things like keepN.
procedure MyWPAppendText( src, dest: TWPRichText );
var
strm: TMemoryStream;
begin
src.ClearHeaderFooter;
strm := TMemoryStream.Create;
try
src.SaveToStream( strm );
strm.Position := 0;
dest.FastAppendParagraph;
dest.LoadFromStream( strm );
finally
strm.Free;
end;
dest.ChangeApplied;
end;Ahhh... FastAppendText is dropping the keepN attribute. Do you have an alternative?
Eric