Regarding "overscan", by which I guess you mean what happens to polygons, or parts of polygons, that fall outside the boundaries of the texture: You're right, although I didn't realize it, that the spec doesn't say what to do about that either.
It seemed obvious to me that the texture should be treated as having an infinitely large border with an alpha value of zero (i.e, areas outside the image bounds should simply show the normal part color.) This could be implemented in OpenGL, for example, using GL_CLAMP_TO_BORDER mode (by setting the border color to the part color); or using GL_CLAMP_TO_EDGE (by adding an extra row and column of pixels on each side); or using the old yucky GL_CLAMP (by doing both).
But you're right, the spec doesn't say that.
I do see that, if the texture is expected to fully cover all of the polygons between TEXMAP START and TEXMAP END, that there would be some practical advantages to extending the perimeter of the image indefinitely (i.e., something like GL_CLAMP_TO_EDGE *without* any padding, which is what it looks like you're doing.)
Note that trying to correctly implement any of these, with the exception of GL_CLAMP_TO_BORDER, makes mipmap generation a real pain. (Imagine a large part with a tiny sticker on it. The areas outside the sticker must be completely unaffected by the colors of the texture interior, regardless of which mipmap is used.)
On the subject of the TEXMAP spec, another serious issue is the definition of gloss maps: "It should be a single channel image where the value indicates the amount of specularity to add at the part of the texture map (RG and B are currently ignored – but reserved – in gloss maps, and the A (alpha) channel determines the amount of gloss at a given texel)."
The first part implies that it should be a type 0 PNG file (grayscale with no alpha channel) and that the significant channel is, well, the only one ("value", i.e. luminance.) The second part contradicts that - technically speaking, there is no such thing as a single-channel PNG with an alpha channel! - and frankly, it makes less sense (why require the image file to include 1 or 3 useless extra channels?) Not to mention that it doesn't do any good to say those channels are "reserved" if you don't tell part authors what value to put there.
It seemed obvious to me that the texture should be treated as having an infinitely large border with an alpha value of zero (i.e, areas outside the image bounds should simply show the normal part color.) This could be implemented in OpenGL, for example, using GL_CLAMP_TO_BORDER mode (by setting the border color to the part color); or using GL_CLAMP_TO_EDGE (by adding an extra row and column of pixels on each side); or using the old yucky GL_CLAMP (by doing both).
But you're right, the spec doesn't say that.
I do see that, if the texture is expected to fully cover all of the polygons between TEXMAP START and TEXMAP END, that there would be some practical advantages to extending the perimeter of the image indefinitely (i.e., something like GL_CLAMP_TO_EDGE *without* any padding, which is what it looks like you're doing.)
Note that trying to correctly implement any of these, with the exception of GL_CLAMP_TO_BORDER, makes mipmap generation a real pain. (Imagine a large part with a tiny sticker on it. The areas outside the sticker must be completely unaffected by the colors of the texture interior, regardless of which mipmap is used.)
On the subject of the TEXMAP spec, another serious issue is the definition of gloss maps: "It should be a single channel image where the value indicates the amount of specularity to add at the part of the texture map (RG and B are currently ignored – but reserved – in gloss maps, and the A (alpha) channel determines the amount of gloss at a given texel)."
The first part implies that it should be a type 0 PNG file (grayscale with no alpha channel) and that the significant channel is, well, the only one ("value", i.e. luminance.) The second part contradicts that - technically speaking, there is no such thing as a single-channel PNG with an alpha channel! - and frankly, it makes less sense (why require the image file to include 1 or 3 useless extra channels?) Not to mention that it doesn't do any good to say those channels are "reserved" if you don't tell part authors what value to put there.