Conference virke::mrmemo

.0> A customer is telling me that MRMEMO, after receiving a message from
.0> an X.400 gateway, sends a fixed length record message (132 characters)
.0> to the intended MEMO recipient: this is done whatever the "original"
.0> (coming from X.400 network) record length is.

    That is correct.

.0> In the customer's opinion this leads sometime to exceed the max MEMO
.0> message dimension (500k about), even if the original message is not so big.
.0> (What I understand here, is that MRMEMO does some filling on the records
.0> of the original message).
.0>
.0> Is what reported by my customer true? Can someone explain what's behind
.0> this kind of behavior?

    Your customer is correct - that's how MRMEMO works.
    You configure MRMEMO with a fixed line length (DEFINE/TEXT_LINES=WIDTH=n).
    This fixed length is applied to all lines that are sent to MEMO.
    Shorter lines are padded with trailing blanks. Longer lines are wrapped 
    onto next line or truncated (configurable).

    The reason for this behaviour is that MEMO regards a document as a
    character matrix. The concept of documents where lines are of different
    lengths is unknown to MEMO (at least in the protcol we use).

    Deciding what line width to use when configuring MRMEMO is not always
    easy, since there are usually conflicting requirements.
    A small line width reduces the padding overhead but might wrap/truncate
    many lines and make the text received on the MEMO side look ugly.
    A large line width doesn't distort the text by cutting long lines, but
    instead you have to pay the padding overhead for the shorter lines.

    Another potential problem with larger line widths that I have heard
    about (but not confirmed) is that MEMO 'knows' how wide a received
    document is and refuses to print it on a printer that is not configured
    for 'wide text'. (Even when the 'wide' text actually is 'narrow' text
    with blank padded lines.)  So using a large line width might restrict 
    the MEMO users' set of available printers for hardcopy output.

    That's how it works today. Some improvements could be made but as
    long as MEMO insists on regarding a document as a rectangular text
    area, space padding must be used.

    Anders

Hi ,

Memo is NOT printing 132line Memos to "normal" printers. You have to 
use a 132 character printer. This is  aproblem that Bosch is still 
mocking about.

I heard that there was a patch for a "dynamic" line length in MRMEMO 
? This is what VW people told my Bosch people.

As far as they told me, MRMEMO determines if the longest line is more 
or less than 80 characters and then decides what to send. Is this 
true ?

If this extists, Bosch would like to have it.

Ute

.2> I heard that there was a patch for a "dynamic" line length in MRMEMO 
.2> ? This is what VW people told my Bosch people.

    The "dynamic line length" in VW's MRMEMO is not the result of a patch.
    VW is running a customized MRMEMO and the "dynamic line length" was
    one of the features that was added to this customized version.
    The customized VW MRMEMO version was created as a project and paid for
    by VW.

.2> As far as they told me, MRMEMO determines if the longest line is more 
.2> or less than 80 characters and then decides what to send. Is this 
.2> true ?

    I haven't checked exactly what the VW version does (Stefan did the job).
    The general idea is to set the MEMO line length to

      max (min (longest_line_in_message, max_allowed_line_length),
           min_allowed_line_length)

    before sending the message to MEMO. In this way, max_allowed_line_length
    can be set quite large to allow wide messages to pass unwrapped but still
    allowing messages with "normal" line lengths to arrive to MEMO without
    the huge line length setting that prevents the message from being printed
    on a "normal"-width printer.

.2> If this extists, Bosch would like to have it.

    We do recognize the need for the dynamic line length functionality.
    It was already high on the wish list when VW required it. When (and if)
    a new MRMEMO version is released, dynamic line length will most likely
    be included.

    It might be possible to create a feature patch that adds this functionality
    to the "vanilla" MRMEMO V2.1. Some values would have to be hardcoded
    though, since patching MRMMAN to include new commands is not realistic.
    To create a dynamic-line-length-patch is something we would have to charge
    for. It could take a day or two to do the job (if it is possible).

    Anders

    
    Clarification:
    
> .2> As far as they told me, MRMEMO determines if the longest line is more 
> .2> or less than 80 characters and then decides what to send. Is this 
> .2> true ?
>
>    I haven't checked exactly what the VW version does (Stefan did the job).
>    The general idea is to set the MEMO line length to
>
>      max (min (longest_line_in_message, max_allowed_line_length),
>           min_allowed_line_length)
>
>    before sending the message to MEMO. In this way, max_allowed_line_length
>    can be set quite large to allow wide messages to pass unwrapped but still
>    allowing messages with "normal" line lengths to arrive to MEMO without
>    the huge line length setting that prevents the message from being printed
>    on a "normal"-width printer.
>
    Anders is right. In practice it means that the line length is always
    set equal to the longest line in the message.
    
> .2> If this extists, Bosch would like to have it.
>
>    We do recognize the need for the dynamic line length functionality.
>    It was already high on the wish list when VW required it. When (and if)
>    a new MRMEMO version is released, dynamic line length will most likely
>    be included.
>
>    It might be possible to create a feature patch that adds this functionality
>    to the "vanilla" MRMEMO V2.1. Some values would have to be hardcoded
>    though, since patching MRMMAN to include new commands is not realistic.
>    To create a dynamic-line-length-patch is something we would have to charge
>    for. It could take a day or two to do the job (if it is possible).
    
    It might be a better idea to provide the actual kit. This would
    certainly require less work for us (though I realise more for you).
    However you must realise that we're reluctant to give something away
    that another customer paid good money for. 
    
    So the message is:
    
    1) The functionality is available.
    
    2) We need to make an agreement with the customer as to how we deliver,
       and at what price. Contact us off-line, copy Tobias Malmgren@SOO
    
    
    	Cheers,
    
    		Stefan