1
0
-1

LayoutPreparationParameter and ImageSetter paramaters have @Sides with a default of "OneSidedFront", but DigitalPrintingParameters does not specify a default and is an optional field. If the field is absent and the RunList does not provide surface binding, what should the behavior be? Should DPP have "OneSidedFront" as the default?

  

    CommentAdd your comment...

    5 answers

    1.  
      2
      1
      0

      Hidden defaults are not a good idea, because that causes unexpected behaviors.
      In addition, I know cases where the absence of parameter was a problem, because the purpose was exactly to use the printer default, and having a default value does not allow that.
      So, if the value is specified, it's clear. If not, it should not depend on a hidden default from the specification but from a default in the device.
      In JDF 2.0, all default will disappear and I think this is good.

       

        CommentAdd your comment...
      1.  
        1
        0
        -1

        when I was discussing defaults, I did not intend to imply XML schema defaults, but documented defaults. I totally disagree with the JDF spec using any XML Schema defaults, since a schema is not used in production, only during testing. The default I was referring to was documented default behavior. I am fine with the document saying the default is a value or the default is the current printer setting at print time, but it does need to be decided and documented so that all print drivers behave the same.

          CommentAdd your comment...
        1.  
          1
          0
          -1

          I agree I dislike defaults, however, its impossible to print without selecting a plex and the field is defined as optional. Either the field must be mandatory, forcing the user to decide the plex, or there must be a default, since some type of plex must be selected to print.

          1. Jean-Marc Steux

            Of course, a value must be specified for printing.

            For many parameters, it really makes sense to have a default defined on the printer itself: either the printer has a default, or the Operator has to decide.

            It's not only for plexity, other parameters could be not present in the JDF ticket, for instance media attributes can be missing.

            Making all parameters mandatory is not a good choice, because the "late binding" mechanism is very common. Having some parameters with a default in the XML schema and others with a default in the printer is very confusing and inconsistent.

            So:

            • If the user really wants a value, he has to specify it. The JDF spec should not allow him to rely on an hidden default value.
            • The mechanism to select the missing values should be the same for all parameters.

            • The mandatory parameters should be limited to the minimum, to allow late binding, i.e. choose at the print time.

            ==> No default by XML schema. Limited mandatory values.

          2. martin goodall

            I fully agree that there should be no schema defaults, that's not what I mean and I personally I would not have any schema defaults in JDF and would deprecate ALL the use of JDF schema defaults.

            In this case, if "late binding" to invoke the processing to match the printer specifics is the preferred "processing default" behavior, that's fine, but it should be documented as such, otherwise one printer implementer may consider the default should be simplex, another may consider the default to be duplex and another consider the default to be the same as the printer characteristics. Have you ever considered introducing a specific keyword to mean "same as printer plex/late binding" so that a generator can be specific? This is helpful since when a JDF is created, the target may not be known and also, what happens if the reprint is to a different device with different characteristics, it gives the user the ability to be specific how to behave.

          CommentAdd your comment...
        2.  
          1
          0
          -1

          IMO there should be a default value (even if its one default for wide and one default for other printers), otherwise the implementation is per developer of a printer controller, and ambiguous behavior occurs.

          I raised the question after receiving a JDF where the customer assumed the default came from LayoutPreparationParams when not specified in DPP and created the JDF assuming this incorrect behavior.

          There is a default for LPP; in my opinion it should be the same default for DPP and not relate to printer format. 

          It would be odd for LPP to default to OneSidedFront and DPP to default to TwoSided. When the sides were placed on paper, with defaults, TwoSided output would occur but the user could easily expect to get simplex while creating the LPP.

            CommentAdd your comment...
          1.  
            1
            0
            -1

            I would suggest to use TwoSided as default (note that JDF1.5 deprecated FlipX and Flipy variations) since most production digital printing is double sided.

            For wide format printing, OneSided would be a good default.

            The ICS could specify that but usually prefers to have the manager provide explicit values.

              CommentAdd your comment...