The band_height calculation divides up the BufferSpace into n bands, but when the page has transparency, the band_height is reduced to try and keep the pdf14 transparency buffers within the BufferSpace, but since the buffers are not allocated from the printer device's 'base' memory (BufferSpace size), the space in the base memory past the reduced band_height is just wasted. Probably we should free and re-allocate the BufferSpace to the size needed for the reduced band_height during rendering, then free and reallocate the original size again after rendering the page. At least this would keep to total RAM needed closer to what was intended with the BufferSpace parameter and the pdf14 clist implementation. This could be a critical issue in an embedded implementation.
Also, in page mode, we should defer allocating the device's page buffer until the PDF14_POP_DEVICE does its put_image since it won't be written into until we use pdf14_put_image to "blit" the pdf14 device's top page buffer into the device buffer. This allows the transparency stack to be allocated when there is no full page device buffer, reducing the RAM high water mark. Also, in page mode, we don't need to clear (fillpage) the device's page buffer since it will be written ENTIRELY from the pdf14 top page buffer.