Page borders

Using the CODM and the new facilities in HW4 to define alternative screens, I find that although screens appear to switch correctly to the required layouts, depending on whether I use a 4:3 screen or a 16:9 screen, in widescreen mode, there is a black border all the way round my background image and I can't place stop icons past the end of the background and over the black border. Is there any way to make Hauptwerk "claim" the entire area of the black border?

Here's typical code for the background:

****************************************************
<CustomDisplay_AlternateLayout1_ConsoleWidthPixels>1350</CustomDisplay_AlternateLayout1_ConsoleWidthPixels><CustomDisplay_AlternateLayout1_ConsoleHeightPixels>666</CustomDisplay_AlternateLayout1_ConsoleHeightPixels>
****************************************************
<AlternateLayout1_Include>Y</AlternateLayout1_Include> <AlternateLayout1_BackgroundImageFilename>ParamountImages/RosewoodW.png</AlternateLayout1_BackgroundImageFilename>
****************************************************
The console image file and the rosewood background file are both 1350 x 666 pixels.

It doesn't seem to matter whether the figures or the size of the actual background image files are increased, HW just scales back to sit inside its enforced border.

The standard 4:3 layout remains unaltered with no enforced border.


Also, when using the alternative screen switch in the ODF, it makes the organ much slower to load, even on an images only ODF. With the switch off and no alt screen positions defined, loading (images only) is almost instantaneous. Whilst I realise that there will be position calculations needed, it does seem to take rather longer than expected. This is also the same when loading outside the compiled ODF outside the CODM. Would it be possible to have the positioning cached, so that at least loading an organ in normal user mode would be much faster?

[mdyde]

Hello Alan,

Using the CODM and the new facilities in HW4 to define alternative screens, I find that although screens appear to switch correctly to the required layouts, depending on whether I use a 4:3 screen or a 16:9 screen, in widescreen mode, there is a black border all the way round my background image and I can't place stop icons past the end of the background and over the black border. Is there any way to make Hauptwerk "claim" the entire area of the black border?

If 'View | Zoom virtual console to fit' is turned on (as it is by default) Hauptwerk should always preserve the aspect ratio of the virtual console layout selected (being that one that best fits within the aspect ratio of the console window), and will show a black border as necessary to pad either the top/bottom or left/right to achieve that. An additional black padding of about 24 pixels is shown on the otherwise-unpadded sides.

The black padding isn't part of the virtual console display, so you can't position images on it. If you want images off the edge of your current virtual console display then you just need to adjust the aspect ratio of your virtual console display (and its background image(s)) accordingly. For example, if you think there's too much padding at the top/bottom when you load the organ on a full-screen 16:9 monitor, then adjust the aspect ratio of your background images/console in the organ definition accordingly so that the virtual console/background is a bit higher.

As another example, a 16:9-aspect background image isn't necessarily perfectly optimal for a 16:9-aspect computer monitor because other things will normally be displayed at the top and bottom of the monitor, such as the menu bar, status bar, docked control panels and docked piston toolbars. Hence you would probably want the aspect ratio of your virtual console to be designed a bit wider than 16:9 to avoid wasting space at the left/right sides.

You can experiment with how the screen zoom, multiple aspect ratio support, and black borders are designed to work using the St. Anne's sample set by dragging the main window taller vs. wider and back again.

It doesn't seem to matter whether the figures or the size of the actual background image files are increased, HW just scales back to sit inside its enforced border.

Yes - that's intended because it's designed to preserve the aspect ratio of the virtual console dimensions you specify as it zooms.

Also, when using the alternative screen switch in the ODF, it makes the organ much slower to load, even on an images only ODF. With the switch off and no alt screen positions defined, loading (images only) is almost instantaneous. Whilst I realise that there will be position calculations needed, it does seem to take rather longer than expected. This is also the same when loading outside the compiled ODF outside the CODM. Would it be possible to have the positioning cached, so that at least loading an organ in normal user mode would be much faster?

Have you perhaps disabled organ definition auto-compacting? (That will make organ definitions very slow to load, but an end-user would never normally do that.) St. Anne's has multiple screen layouts and its organ definition loads quickly.

Thanks Martin.

If 'View | Zoom virtual console to fit' is turned on (as it is by default) Hauptwerk should always preserve the aspect ratio of the virtual console layout selected (being that one that best fits within the aspect ratio of the console window), and will show a black border as necessary to pad either the top/bottom or left/right to achieve that. An additional black padding of about 24 pixels is shown on the otherwise-unpadded sides.

The black padding isn't part of the virtual console display, so you can't position images on it. If you want images off the edge of your current virtual console display then you just need to adjust the aspect ratio of your virtual console display (and its background image(s)) accordingly. For example, if you think there's too much padding at the top/bottom when you load the organ on a full-screen 16:9 monitor, then adjust the aspect ratio of your background images/console in the organ definition accordingly so that the virtual console/background is a bit higher.

As another example, a 16:9-aspect background image isn't necessarily perfectly optimal for a 16:9-aspect computer monitor because other things will normally be displayed at the top and bottom of the monitor, such as the menu bar, status bar, docked control panels and docked piston toolbars. Hence you would probably want the aspect ratio of your virtual console to be designed a bit wider than 16:9 to avoid wasting space at the left/right sides.

You can experiment with how the screen zoom, multiple aspect ratio support, and black borders are designed to work using the St. Anne's sample set by dragging the main window taller vs. wider and back again.

I now see what you mean about aspect ratio, rather than actual screen sizes.

I was trying to claim the 24 pixel border at each side of the page view, but obviously that's not possible.

TBQH on my laptop which has a recommended resolution of 166 x 768, I can't see a lot of difference in the two views of St Anne's. Looking at the "all frills" custom definition, I see there is a noticeable difference, so maybe it's just something about my laptop that is causing the problem?

Have you perhaps disabled organ definition auto-compacting? (That will make organ definitions very slow to load, but an end-user would never normally do that.) St. Anne's has multiple screen layouts and its organ definition loads quickly.

I didn't know that you could disable auto-compacting via CODM files. Perhaps I misled you into thinking it was a full ODF?

I've solved the problem. I think it was an ID conflict with a custom organ that had previously been installed. I uninstalled all previous custom organs that were no longer needed and after a re-load, it's now up to speed.

[mdyde]

Hello Alan,

TBQH on my laptop which has a recommended resolution of 166 x 768, I can't see a lot of difference in the two views of St Anne's. Looking at the "all frills" custom definition, I see there is a noticeable difference, so maybe it's just something about my laptop that is causing the problem?

The v4 St. Anne's has horizontal and vertical virtual console layouts for the left and right jamb pages (only). Since the menu bar and status bar would normally prevent the main window being made very narrow, you would probably only be able to see/test the vertical console layout on your (fairly low resolution) laptop if you opened a second console window (which could be made very narrower than it is tall for testing, since it won't have a menu or status bar).

With a high resolution monitor (e.g. I use an Apple monitor at 2560x1600) you can do the same thing with the main window.

I didn't know that you could disable auto-compacting via CODM files. Perhaps I misled you into thinking it was a full ODF?

Correct - CODM organ definition files are never compacted. However, a CODM ODF always compiles to a 'full-format' ODF when you load it and then the full-format ODF is loaded. You can disable auto-compacting for full-format ODFs, which could still result in the CODM ODF taking longer to load in total, since the full-format ODF it had compiled to would be slower to load.

I've solved the problem. I think it was an ID conflict with a custom organ that had previously been installed. I uninstalled all previous custom organs that were no longer needed and after a re-load, it's now up to speed.

Excellent.