| | | | |
| |
| In lugnet.cad.dev, Miguel Agullo writes:
> Hi Kevin,
>
> You've done it again! This is a HUGE improvement as it allows a much needed
> "step hierarchy", extremely useful for generating instructions - your step 0
> is actually two steps. This is really great.
>
> I am probably being too inquisitive too early, but how are the coordinates
> for the callout placements and pointers resolved? Are they tied to a
> determined resolution of the final output? Does Lpub change them
> automatically if the output resolutions is changed?
I was thinking more about this (and I've asked Miguel to help me with the
resolution independent architecture of the new LPub features), and there are
two *different* issues here.
Issue 1:
I want to render everything in low resolution (to save time) until I get things
they way I want, then I want to increase the resolution for the final draft,
and have everything scale accordingly. The final draft is destined for the
web, so when I raise the resolution, I don't want the borders and callout
seperators and such to increase in size.
Issue 2:
I want to render everything in low resolution (to save time), but when I
increase the resolution for printing, I want the borders ans callout seperators
to increase in thickness, so they look right when they are printed.
How do we address the conflict between these two wants?
This whole *resolution indepence* is a very good idea, and especially now in
the beginning of the *LPub for page layout* era, before things get too
entrenched. But.... it is a new concept for me to deal with.
Kevin
| | | | | | | | | | | | |
| |
| <snip>
>
> I was thinking more about this (and I've asked Miguel to help me with the
> resolution independent architecture of the new LPub features), and there are
> two *different* issues here.
>
> Issue 1:
> I want to render everything in low resolution (to save time) until I get things
> they way I want, then I want to increase the resolution for the final draft,
> and have everything scale accordingly. The final draft is destined for the
> web, so when I raise the resolution, I don't want the borders and callout
> seperators and such to increase in size.
>
> Issue 2:
> I want to render everything in low resolution (to save time), but when I
> increase the resolution for printing, I want the borders ans callout seperators
> to increase in thickness, so they look right when they are printed.
>
> How do we address the conflict between these two wants?
>
> This whole *resolution indepence* is a very good idea, and especially now in
> the beginning of the *LPub for page layout* era, before things get too
> entrenched. But.... it is a new concept for me to deal with.
I wanted to point out that the callout facilities (which I am starting to think
of as step layout facilities), is all *post* POV production work, which means
it is instantaneous compared to POV time. Making modifications to the post
*POV* stuff is cheap, this makes me less concerned about resolution independent
stuff. Anyplace where I know just what to do I'm going to change right away
(like the pointers from callouts to step images.)
Many of the step-layout meta-commands just define values that are used in the
future. This is handy because you can place these parameter setting
meta-commands at the top of your highest level model's file and they'll apply
for the rest of that file, including any sub-models it calls out.
This makes it easy to change the values after you've changed the resolution and
cranked up all your images.
I'm going to modify a few of the meta-commands to make this even more
advantageous, decreasing the *stress* related to resolution independence.
I also wanted to hint at the *next step* in LPub's rapidly changing
architecture. Page-layout. It shares many things with step-layout, but will
be used to combine multiple steps into a page. Here is an example of the
page-layout facilities I want:
http://library.brickshelf.com/scans/8000/8042/8042-01.html
Kevin
| | | | | | | | | | | | | | |
| |
| <snip>
>
> I was thinking more about this (and I've asked Miguel to help me with the
> resolution independent architecture of the new LPub features), and there are
> two *different* issues here.
>
> Issue 1:
> I want to render everything in low resolution (to save time) until I get things
> they way I want, then I want to increase the resolution for the final draft,
> and have everything scale accordingly. The final draft is destined for the
> web, so when I raise the resolution, I don't want the borders and callout
> seperators and such to increase in size.
>
> Issue 2:
> I want to render everything in low resolution (to save time), but when I
> increase the resolution for printing, I want the borders ans callout seperators
> to increase in thickness, so they look right when they are printed.
>
> How do we address the conflict between these two wants?
>
> This whole *resolution indepence* is a very good idea, and especially now in
> the beginning of the *LPub for page layout* era, before things get too
> entrenched. But.... it is a new concept for me to deal with.
I wanted to point out that the callout facilities (which I am starting to think
of as step layout facilities), is all *post* POV production work, which means
it is instantaneous compared to POV time. Making modifications to the post
*POV* stuff is cheap, this makes me less concerned about resolution independent
stuff. Anyplace where I know just what to do I'm going to change right away
(like the pointers from callouts to step images.)
Many of the step-layout meta-commands just define values that are used in the
future. This is handy because you can place these parameter setting
meta-commands at the top of your highest level model's file and they'll apply
for the rest of that file, including any sub-models it calls out.
This makes it easy to change the values after you've changed the resolution and
cranked up all your images.
I'm going to modify a few of the meta-commands to make this even more
advantageous, decreasing the *stress* related to resolution independence.
I also wanted to hint at the *next step* in LPub's rapidly changing
architecture. Page-layout. It shares many things with step-layout, but will
be used to combine multiple steps into a page. Here is an example of the
page-layout facilities I want:
http://library.brickshelf.com/scans/8000/8042/8042-01.html
Kevin
| | | | | | |