Welcome Guest Search | Active Topics | Sign In | Register

Filling in form field with a Swedish characters (or how to set encoding?) Options
eo_support
Posted: Tuesday, April 3, 2018 6:39:08 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
We have emailed you a new private build. Please let us know if you still see any problems.

Thanks!
Maxim
Posted: Wednesday, April 4, 2018 2:43:37 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
Hi,

Thanks! I'll test ASAP and will get back with the result.
Maxim
Posted: Wednesday, April 4, 2018 6:50:52 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
Hi,

As you wrote me in the email, this build breaks an existent functionality of showing values in the fields with invalid fonts. I don't get why they are invalid (it's either Arial or TimesNewRoman, see example in email), but your previous build (the latest one right now) shows the values in it and another lib does (you know which). Just this build doesn't.

Please see the image: the link to the image.

The file I sent you now has TimesNewRoman font in fields. The same issue happens if I change the font to Arial (I'm not going to use Arial, just tell it). And Adobe adds characters into the fields when I type there. So does Google Chrome.

Seems like you fixed the previous issue with Adobe by removing some other functionality which is crucial to have.

Can it work like it does in the build 18.1.31 but without Adobe issue I wrote about yesterday?

I'll send you the files now replying to the yesterday's email with a link to the new build from Jack.

Best regards,
Maxim

PS:
- I also think your latest build fails to get the font from *some* fields and shows default Arial when EO.Pdf v 17.2.43 detects the font name perfectly.
- and there is also an issue when your latest build shows TWO lines in textbox with single line mode if the font size is fixed (say 10) and the value is too long; I can handle it by setting the font size to 0 so the font size is Auto, but still you may want to fix that.
eo_support
Posted: Wednesday, April 4, 2018 9:01:39 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
There are two different issues here. One is to preserve existing font data, one is to replace it with new font data. The new font data is important for programmatically filled value (characters known to our code), while existing data is important for user entered value (characters not known to our code).

When we completely rely on new font data (old builds that works) it can render programmatically filled data correctly because we know all the character we put in the field, thus we can correctly generate the necessary font data for all those characters. This wasn't the case initially though --- it wasn't generating font data correctly for Swedish characters. That issue has been fixed in build 18.0.98.

However at this point it would still completely replace existing font data with new font data, which is limited to characters known to our code, this would cause problem with user entered value. As such we changed our code to rely on existing font data when your code does not change font. This was the fix in build 18.1.31. This fix allows user entered value to be displayed correctly.

This also means that now if you do not change font, it will rely on existing font data, and if there is a problem with existing font data, then things won't be displayed correctly. This is what happened with the last build that "broke" the previous "Comment Arial" field. The font data for this field was wrong to the point that even if you enter any character directly in that field it won't display. So this is not a regression bug ---- it's just an existing issue being exposed. We can not switch to our new font data (as build 18.0.98) either because then user entered value won't work.

It is our goal for our library to be as tolerable as it can --- which means even if there are minor issues in the input PDF files, we will attempt to automatically fix/recover in our code. In fact we did address one such issue with yesterday's build. The reason that build .31 wasn't displaying space correctly in Chrome was because the font data associated to the field was missing Encoding property. Adobe Reader can handle this fine but Chrome couldn't. We have changed our code in build .33 that automatically fixes such error in the PDF file.

I certainly understand your frustration, but please understand that with each iteration we are making improvement. While from your end it does seem that there are problems after problems and even old problems showed up in our product, from our end we see problems after problems in your input PDF file and with every new build our product is able to tolerate more. Fortunately most of the time you have another library that can handle such errors so we have a rather clear reference to follow. We appreciate such help very much and we will work with you to get the best result possible. Now it appears that we need to properly merge new font data and existing font data in order to get the best result for both cases (programmatically filled value and user entered value), this can take some time. So please bear with us and we will update you as we make progress.


Maxim
Posted: Wednesday, April 4, 2018 9:23:05 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
Hi guys,

Thank you for this detailed explanation of what's happening. I do belive that you do lots of improvements and I appreciate the speed and your efforts to solve all these issues.

Quote:
Now it appears that we need to properly merge new font data and existing font data in order to get the best result for both cases (programmatically filled value and user entered value), this can take some time.

Can I get an estimate when you think a new build can be ready? Just so I can plan.

Best regards,
Maxim
eo_support
Posted: Wednesday, April 4, 2018 9:52:09 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
We are still evaluating the issue now so we do not have an accurate time line yet. I would put an estimate of one week for now. We will update you when we have a more clear picture.
Maxim
Posted: Wednesday, April 4, 2018 9:53:24 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
I see, thanks for the info.
eo_support
Posted: Wednesday, April 4, 2018 9:37:25 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
We have sent you a new build. Please take a look and let us know how it goes.
Maxim
Posted: Thursday, April 5, 2018 2:56:01 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
Hi,

Thank you for the new build. I'll start looking at it now and will get back with the results!
Maxim
Posted: Thursday, April 5, 2018 5:01:09 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
I'm still testing. Meanwhile noticed other two fields in one document which don't get the value shown (it's inserted, but is not shown until the focus is added into a field). Could you please look at that? I've sent the test file to your email box.
Maxim
Posted: Thursday, April 5, 2018 7:26:12 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
I also found a file where EO.Pdf shows null in Color and Font properties on some fields. I assume something is invalid in those fields, but PDF editor tools shows the font right (Helvetica / Auto). I've just sent the file to your support email replying to Jack's email. You may like to have a look at this as well.

It doesn't stop me from filling the values into these fields, because I use such snippet, but still letting you know about it.

Code: C#
if (field.Font != null)
  field.Font.Size = 0;
else
  field.Font = new PdfFont("Helvetica", 0);
Maxim
Posted: Thursday, April 5, 2018 8:43:22 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
And I also found 1 file where the whole process hangs (takes more than minutes, then I stopped the process) to save the file if 1 field gets a value with Environment.NewLine in it and the font size is set to 0 (i.e. Auto):

Code: C#
var pdf = new EO.Pdf.PdfDocument(file);
	
pdf.Fields["SecondName"].Font.Size = 0; // with this line commented out the process doesn't hang on saving
	
pdf.Fields["SecondName"].Value = "FirstName LastName" + Environment.NewLine + "CompanyName";
	
pdf.Save(filledInFile);


I'll send the mail with the file to your support email in a few mins. EO.Pdf version 17.2.43 inserts this value without an issue. Could you please look at this as well?

I'm done with the test for now. I'll test the next build with these 3 issues which I found today fixed (I hope!) on all files again.

Thanks,
Maxim
eo_support
Posted: Thursday, April 5, 2018 2:37:55 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

We have just sent you another new build. Please take a look and let us know how it goes.

Thanks!
Maxim
Posted: Friday, April 6, 2018 7:28:20 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
Hi,

I'll look at it now and will get back to you then!
Maxim
Posted: Friday, April 6, 2018 8:07:45 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
Hi,

Now font size detection goes crazy on the file I sent you yesterday to demonstrate the issue with NULL in Font and Color.

Look at this image: the link to the image

Version 2018.1.34 calculates the auto font size right.

I've sent the code and the file to you.

Best regards,
Maxim
eo_support
Posted: Friday, April 6, 2018 3:02:52 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
We have sent you build .36 that should resize the font correctly for this file.
Maxim
Posted: Monday, April 9, 2018 11:53:14 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
Hi,
eo_support wrote:
We have sent you build .36 that should resize the font correctly for this file.

This sounded strange for me when I read it, but was it really fixed for that file only?

Another file, the same issue: the link to the printscreen.

I've sent the test file with code to your support mail.

Is it possible to fix this issue for all files, not only these two?

Best regards,
Maxim
eo_support
Posted: Monday, April 9, 2018 12:48:16 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
I think you are taking our reply a bit too literally. We will look into the new file and see what we find. We do not fix issue just for one file ---- we find out how the issue is triggered using the file you provided and fix the root cause for that particular issue. It is possible that you have other files that would represent a completely different code path, would contain a different error or rarely used syntax, or even present a case where it is not possible for us to support automatic font resizing, etc, but they can result in the same symptom. Just like there can be a million different disease that will all lead to headache. In another word, not all problems that have the same symptoms are the same problems. Obviously when we respond to you that we have fixed an issue we can only tell you that we have fixed the issue demonstrated by the test file you provided. We won't tell you that it will fix all problems for you because that's simply not true. Another file that may demonstrate the same symptom but can be a totally different issue. So we go over them one by one.
Maxim
Posted: Tuesday, April 10, 2018 7:27:10 AM
Rank: Advanced Member
Groups: Member

Joined: 12/18/2013
Posts: 67
Hi,

Yes, I understand it of course, but it was not that funny coincidence to run into another similar issue with font size right after you fixed font size issue in the previous file. I think we both are a bit tired of these issues, so every next issue I found is a stress for me and I think for you as well.

How is the fix going? When can I expect to try another build?

Best regards,
Maxim
eo_support
Posted: Tuesday, April 10, 2018 10:47:22 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

We have looked into the latest file you sent to us and with this file the product actually seems to be working as expected.

The issue at here is auto resizing font. This is a feature our library supported but it only kicks in when the field's font size is indeed set to auto resize. For this particular file, if you open the file in an PDF editor such as Adobe Acrobat, you will see all the field's font sizes are explicitly set to 10. When a font size value is explicitly set, we need to honor it, even if it means the text will overflow the field.

If you set the font to auto resize in Acrobat, then we will see that flag and will perform auto resizing. Alternatively, you can explicitly set the font size to 0 in your code to trigger auto resizing font. These two are the same ---- when you set font to auto resize in Acrobat, it sets the font size to 0.

Please let us know if you still have any questions.

Thanks!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.