Clovertech

PNG Images

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › PNG Images

  • Creator
    Topic
  • March 6, 2006 at 6:13 pm #48379
    Jacques B
    Participant

      Hi,

      I’m trying to pass PNG images.  The problem is I’m receiving sometimes a x0b  which means new message.  Since the message is defined this way in the pdl:  

      define phrase basic-msg;

         ;

         field data = variable-array( not( ) );

         ; ;

      end phrase;

      I have this kind of problem:

      32 33 7c 46  7c 89 50 4e  |23|F|.PN|

      47 0d 0a 1a  0a           |G….|

      03/06/2006 11:04:30

      [pdl :PDL :ERR /0:conn_Radimage] no-match: no more phrases to try

      –> Data received does not match MLP phrase (2 bytes):

      0b 12                     |..|

      03/06/2006 11:04:30

      [pdl :PDL :ERR /0:conn_Radimage] no-match: no more phrases to try

      –> Data received does not match MLP phrase (7 bytes):

      0b 12 01 d2  dd 7e fc     |…..~.|

      So I thought about some solutions:

      1)   Hoping I won’t have an image with “MSH|”

      define phrase basic-msg;

         ; “MSH|”;

         field data = variable-array( not( ) );

         ; ;

      end phrase;

      and since I want to have the field data with the MSH I add this to

      hci_pd_msg_style acknak phrase:basic-msg

      field:”MSH|” data

      resync:\xb

      instead of :

      hci_pd_msg_style basic phrase:basic-msg

      field:data

      resync:\xb

      2) never use image in interfaces.  Use ftp instead.

      3) ask my provider to change by something else.

      Any other idea?  Which solution I should use?

    • Creator
      Topic
    Viewing 4 reply threads
    • Author
      Replies
      • March 6, 2006 at 7:47 pm #58454
        Jim Kosloskey
        Participant

          Jacques,

          If the sending system is agreeable you could change from HL/7 mlp encapsulation to length encoded TCP/IP.

          However, your receiving systems will all need to change as well.

          There is a construct defined in the HL/7 standard which references the passing of images. Perhaps you can gain some insight there – I have never had an occasion to use it.

          Even if you clear the vt hurdle, you need to be aware of the ending encapsulation fs cr as that combination can occur within images as well.

          If the vendor changes the encapsulation characters (hopefully using the escape technique described in the HL/7 standard – Chapter 2 Section 9), the receiving systems must be able to convert them back properly or you need to do it in the engine prior to delivery.

          Images can be quite large and that may pose a performance and/or capacity issue for you.

          Many simply pass a URL or directory/file name in the HL/7 message and the receiving systems fetch the images independently of the message.

          Jim Kosloskey

          email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

        • March 7, 2006 at 6:54 pm #58455
          Scott Folley
          Participant

            Can you have them use base64 encoding on the image data before they send it to you?  If so you can get executables that will decode the image on your side and avoid the problem completely.  Base64 encoding is a fairly common method for transferring image data so you may find that the systems that you are sending to will be able to handle the decoding on their end.

          • March 7, 2006 at 7:04 pm #58456
            Jacques B
            Participant

              Scott,

              that’s exactly what we are trying to do!  We’ll encode the image in Base64.  They suppose to do it by tomorrow and I was waiting to see if this solution was working before to send it…

              Thank you.

            • April 4, 2006 at 10:00 am #58457
              Jacques B
              Participant

                But not the best idea…

                With base64, we pass images (PNG and JPeG).  I needed to do it but I don’t recommend it.  Send a the place where the file is, a URL instead.

              • April 5, 2006 at 2:56 pm #58458
                Anonymous
                Participant

                  Jacques,

                  Another option, if you have some influence over the the sending system, is to switch from encapsulation to length encoding.  Then the individual bytes won’t matter.

                  Your transmission would go from:

                  <0b>hello <0b>world<0d>

                  To:

                  <00><00><00><10>hello <0b>world

                  (This is 4 byte, binary, length encoding.  There are a total of 16 characters in the transmission including the length field, the <10> in hex is ascii 16)

                  In Cloverleaf, this would be a configuration change and not a PDL.

                  cheers,

              • Author
                Replies
              Viewing 4 reply threads
              • The forum ‘Cloverleaf’ is closed to new topics and replies.