Community

How to pass AlternateLayountName into Block

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"?
0

Comments

12 comments

  • Avatar
    Anastasiya Nechaeva
    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
  • Avatar
    Maciek
    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
  • Avatar
    Slowdima
    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.
    0
  • Avatar
    Maciek
    Thank you very much That works
    0
  • Avatar
    Pawel
    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
  • Avatar
    Slowdima
    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
  • Avatar
    Pawel
    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
  • Avatar
    Slowdima
    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
  • Avatar
    Pawel
    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
  • Avatar
    Slowdima
    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
  • Avatar
    Pawel
    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
  • Avatar
    Pawel
    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.