//

      // There are a whole bunch of situations where we know the length of an OVC

      // element without having to know the value.

      //

      // We restrict OVC so that we know its length without having to know the value

      // so that we can skip forward past the OVC element, and we know the absolute bit position

      // of the thing following it. This lets us deal with alignment regions in that when

      // we try to unparse an alignment region, we can answer the question of how we're aligned

      // currently, so we can determine how many bits to skip.

      //

      // If we allow OVC elements to be variable length where the length depends on the value,

      // then as we unparse forward, if we encounter the need to insert an alignment region, well

      // we don't know the alignment until we know the variable length of the preceding OVC

      // element, so we have to wait for that expression to get its value. But that value

      // may not be forthcoming unless we can continue to unparse. So we have to suspend inserting

      // the alignment region, split off a new buffering dataOutputStream, and come back

      // to filling in the alignment region once we have the length of the OVC element.

      //

      // This is all very complex. For now we want the OVC element to be such that

      // we can determine its length without the value.

      //

      // TODO: add recognition of more cases where we know the length without the value

      // or implement the complex splitting/buffering for alignment after a variable-length

      // OVC element. (This seems obscure enough that it may never come up in real formats.)