| |
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?
Any chance of a WYSIWYG interface;-)?
Excellent stuff!
|
|
| |
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?
The callouts are placed relative to outside edges or corners of the step image:
Corners:
TOP_LEFT
TOP_RIGHT
BOTTOM_LEFT
BOTTOM_RIGHT
Edges plus justification to the perpendicular edges
TOP (LEFT, CENTER or RIGHT)
BOTTOM (LEFT, CENTER or RIGHT)
RIGHT (TOP, CENTER, BOTTOM)
LEFT (TOP, CENTER, BOTTOM)
This gives you a total of 16 locations, plus you can offset from there by
providing an x and y offset (in pixels).
TOP_LEFT | TOP/LEFT TOP/CENTER TOP/RIGHT | TOP_RIGHT
-------------------------------------------------------------------------
LEFT/TOP | | RIGHT/TOP
LEFT/CENTER | | RIGHT/CENTER
LEFT/BOTTOM | | RIGHT/BOTTOM
-------------------------------------------------------------------------
BOTTOM_LEFT | BOTTOM/LEFT BOTTOM/CENTER BOTTOM/RIGHT | BOTTOM_RIGHT
You also can place the Part List Image relative to the step image using the
same mechanism.
Finally you can place the step number relative to either the PLI or the step
image using the above mechanism.
The pointers from callouts into the step image are described relative to the
side of the callout closest to the step image, and pixel offsets into the step
image.
>
> Any chance of a WYSIWYG interface;-)?
There are always possibilities :^)
>
> Excellent stuff!
Thanks!
Kevin
|
|
| |
In lugnet.cad.dev, Kevin Clague writes:
> 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?
>
> The callouts are placed relative to outside edges or corners of the step image:
>
> Corners:
> TOP_LEFT
> TOP_RIGHT
> BOTTOM_LEFT
> BOTTOM_RIGHT
>
> Edges plus justification to the perpendicular edges
>
> TOP (LEFT, CENTER or RIGHT)
> BOTTOM (LEFT, CENTER or RIGHT)
> RIGHT (TOP, CENTER, BOTTOM)
> LEFT (TOP, CENTER, BOTTOM)
>
> This gives you a total of 16 locations, plus you can offset from there by
> providing an x and y offset (in pixels).
>
> TOP_LEFT | TOP/LEFT TOP/CENTER TOP/RIGHT | TOP_RIGHT
> -------------------------------------------------------------------------
> LEFT/TOP | | RIGHT/TOP
> LEFT/CENTER | | RIGHT/CENTER
> LEFT/BOTTOM | | RIGHT/BOTTOM
> -------------------------------------------------------------------------
> BOTTOM_LEFT | BOTTOM/LEFT BOTTOM/CENTER BOTTOM/RIGHT | BOTTOM_RIGHT
Well I guess the above "ascii draw" diagram didn't work too well with
proportional fonts. Oh, well.
>
> You also can place the Part List Image relative to the step image using the
> same mechanism.
>
> Finally you can place the step number relative to either the PLI or the step
> image using the above mechanism.
>
> The pointers from callouts into the step image are described relative to the
> side of the callout closest to the step image, and pixel offsets into the step
> image.
Per Jennifer Clark's recommendation in private, I'm going to convert the
pointer units from pixels to scaling factors from 0 to 1, where 0,0 is the
upper left corner of an image, and 1,1 is the lower right corner. This way
it is resolution independant.
I'm going to try to revise all the uses of pixels as units to something
resolution independent.
Kevin
>
> >
> > Any chance of a WYSIWYG interface;-)?
>
> There are always possibilities :^)
> >
> > Excellent stuff!
>
> Thanks!
>
> Kevin
|
|
| |
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
|
|
|
