Community

How to pass AlternateLayountName into Block

October 05, 2015 13:05
12

Hi All,

I have FlexiLayout (9.0) template with 3 alternative templates inside (A, B & C)

I have also a block called A_TEMPLATE_NAME.

I would like to know how to pass a chosen by ocr template name (or just static text)

for example if FlaxiLayout choose template B how to pass into A_TEMPLATE_NAME static string "B"?

Comments

12 comments

Anastasiya Nechaeva

October 07, 2015 00:34
Hi Maciek,

The corresponding method of rules scripts exists only for FlexiLayout 10.0 (IPage :: MatchedSection : IMatchedSectionInfo :: FlexibleAlternativeName() : string).

In FlexiLayout 9.0 you can use the following workaround:

1) Create block LayoutAlternativeName on the FlexiLayout level
2) Create Region element in the each FlexiLayout Alternative. This element should be a block source. For each Alternative set the different region. Let's say, for the first one RestrictSearchArea: Rect(0mm, 0mm, 10mm, 10mm ), for the second one RestrictSearchArea: Rect( 10mm, 0mm, 20mm, 10mm ) and so on.
3) To declare on the FlexiCapture level that this field is not recognizable and fill an Alternative with its name using a script rule depends on region coordinates.

0
Maciek

October 07, 2015 09:57
Hi Anastasiya

Thank you for your response. Point 1 & 2 are clear - I created LayoutAlternativeName block and regions Reg_A, Reg_B & Reg_C with different RestrictSearchArea in Advanced pre-search conditions.
These regions are block source.
My problem is that I have no idea about how to write such script in FlexiCapture.
Could you provide me some example how to do it?

0

Slowdima

October 07, 2015 14:04

Hi Maciek.

Let for your auxiliary field you specified the following regions.

In the first layout alternative:



	//*****************


	RestrictSearchArea: Rect(0dt, 0dt, 100dt, 100dt);


	//*****************

In the second:



	//*****************


	RestrictSearchArea: Rect(0dt, 0dt, 100dt, 200dt);


	//*****************

in the third:



	//*****************


	RestrictSearchArea: Rect(0dt, 0dt, 100dt, 300dt);


	//*****************

And so on. Then in the document definition create a script rule, add the auxiliary field into the list of participating fields of the rule, allow to modify the field by the rule by disabling "read-only" checkbox to the right of added field name. In code of the rule populate the field by layout alternative name depending on ratio of region height to width. The script can look as follows (VBScript):



	‘***********************


	Dim sVal, intRatio, oRect


	 


	sVal = “”


	Set oRect =  Me.Field(“LayoutAlternativeName”).Regions(0).SurroundingRect


	intRatio = CInt( (oRect.Bottom – oRect.Top) / (oRect.Right – oRect.Left) )


	 


	Select Case intRatio


	        Case 1


	                       sVal = “Alternative_1”


	        Case 2


	                       sVal = “Alternative_2”


	        Case 3


	                       sVal = “Alternative_3”


	End Select


	 


	Me.Field(“LayoutAlternativeName”).Text = sVal


	‘***********************

Ratio is better than direct check of the boundaries values, because in the last case you will need to convert pixels obtained in the script to dots/mms assigned in the FlexiLayout.

Maciek

October 07, 2015 17:42
Thank you very much That works

0
Pawel

January 29, 2016 10:44
Hi All,
I am trying to solve similar problem, but I have much more alternative templates (about 50). I've noticed that up to template 9 pattern Slowdima suggested works fine. But with higher numbers it fails. For example template 16 is restricted as below:

//*****************

RestrictSearchArea: Rect(0dt, 0dt, 10dt, 160dt);

//*****************

If I understand it correctly intRatio in this case is 16. Unfortunatelly it returns value 12. I've even checked values of singular Apex of Rectangle and value 160dt from Flexi Layout turns out to be 161 in Flexi Capture. Why does this mistake occur?

Do you have any idea how I can assign regions to 50 templates? (I have version 9.0 just like @Maciek)
0
Slowdima

January 29, 2016 12:16
Hi Pawel. The difference between 160dt in FLS and 161px in FC9 is not so weird, since accuracy of boundaries calculation is 1dt and also image preprocessing in FC might be not equal to that in FLS. However, such a small difference of cource may not lead to the described situation.

Could you please specify here all current values of oRect.Right, oRect.Left, oRect.Bottom, oRect.Top, oRect.Right-oRect.Left, oRect.Bottom-oRect.Top, (oRect.Bottom-oRect.Top)/(oRect.Righht - oRect.Left)? You can either see these values in Visual Studio ( just use stop breakpoint in the script and agree to debug when you will see a message about script breakpoint during runtime ) or modify the last line of the rule to print the values into the field. For example:

Me.Field("LayoutAlternativeName").Text = "Left bound: " & CStr( oRect.Left ) & "; Right Bound: " & CStr( oRect.Right )
0
Pawel

January 29, 2016 12:53
Slowdima Thanks for quick answer! I did not notice this, but FC actually adds 1 when converting from dt to px: Left bound: 0; Right Bound: 11; Top Bound: 0;Bottom Bound: 161.

I guess that adding one zero would bypass this problem? eg.: RestrictSearchArea: Rect(0dt, 0dt, 100dt, 1600dt);

0
Slowdima

January 29, 2016 13:20
Hi Pawel.

I think that actual reason is that all block regions are auto-inflated by 1dt to all sides when passed into FC. This is probably done to avoild occasional truncation of characters within the field region and worsening OCR quality because of that. In our certain case inflation to left and top did not happen, because these sides are bound to axes ( so, abscissa -1dt and ordinate -1dt do not exist ). Otherwise the difference in height and width would be 2 pixels instead of 1.

Your workaround should work. However, if I am right, then you also can just modify the ratio to

intRatio = CInt( (oRect.Bottom – oRect.Top - 1) / (oRect.Right – oRect.Left-1) )

Unfortunately, this will be correct only for 300dpi images. Otherwise 1dt != 1px.

0
Pawel

February 01, 2016 11:36
Workaround with "-1" works fine. Thanks!

I've uploaded some 72dpi images and the pattern also works. So did you mean that it will be correct for images UP TO 300dpi and OVER 300dpi it will not work?

0
Slowdima

February 01, 2016 12:14
I expected that inflation is performed by 1dt (1/300 inch). So, with 72 dpi resolution the offset would be 1dt = 72px/300 instead of 1 px. You can debug in the earlier described way to understand if the offset depends on resolutuion. Maybe the offset is rounded to the ceil integer, this would explain your result. Could you please try with 600dpi? if I am right, then the offset will be 2.

0
Pawel

February 01, 2016 13:18
I have a feeling that offset doesn't depend on DPI but rather Resolution (or maybe both?). When I tried with larger file (around 3500px x 5000px) the offset was 3 (with 72 dpi).

With PDF file it's even more interesting : Bottom from 10 changed to 2 while Right changed from 16 to 17.

EDIT: My mistake, it changed from 2 to 1. Which should be fine

0
Pawel

February 01, 2016 16:26
Adding one zero to Bottom and Right fixes the problem. With higher numbers adding 1 or even 5 doesn't change that much in the outcome.

0

Please sign in to leave a comment.

Community

How to pass AlternateLayountName into Block

Comments

Didn't find what you were looking for?