Issue 12 in dyknow-panel-extractor: Resized and moved ink is not rendered properly
dyknow-pane...@googlecode.com
Owner: jjhatf02
Labels: Type-Defect Priority-High Project-DPXReader Component-UI
New issue 12 by jjhatf02: Resized and moved ink is not rendered properly
http://code.google.com/p/dyknow-panel-extractor/issues/detail?id=12
DyKnow's history feature means that the original ink strokes are not
modified when a pen stroke is moved or resized.
For example:
<PEN UT="1" PW="1024" PH="768" UID="fb6bf352-2fad-47c1-958d-ba0711d07022"
DATA="base64:AC0DEEgQRWobAgBZ/0ZqGwIAWf8RAACAPx8JEQAAAAAAAPA/CgkCDDT1RQw+1CI="
/>
<EDOB UT="1" SP="2715:1025" EP="3324:1184" PW="1024" PH="768"
UID="56beb867-be67-4ebf-8e3c-b141e299e8bf" ISREM="false">
<EDLI>
<EDDE OBJID="fb6bf352-2fad-47c1-958d-ba0711d07022" />
</EDLI>
</EDOB>
The way the resize works is by setting a new bounding box for the specified
unique objid's included in the modification.
Implementing this functionality will be very difficult, especially since
this applies to multiple object types.
dyknow-pane...@googlecode.com
Comment #1 on issue 12 by jd...@remember.com: Resized and moved ink is not
rendered properly
https://code.google.com/p/dyknow-panel-extractor/issues/detail?id=12
Its not *that* hard. What it does is define the new bounding box of the
collection of objects. So lets say we have 5 ink strokes we lasso. Move
those 5 ink strokes to the right and you will end up with a bounding box
with an identical width/height but a new left/top.
If instead you were to scale those up x2, you would have an identical
left/top but the width/height would be x2. In any case, you just determine
the scale and translation necessary to get from boundsA to boundsB. Then
you apply that matrix to each individual element selected from EDLI. This
does mean you have to have applied all prior edits in-order to get the
correct information. That likewise means you *have* to have correct ISF
parsing or it might even warp any other resized/moved objects when it
calculates their new bounding box. Probably better to send the sx sy tx ty
values directly to avoid such corruption. I'll file a bug as that makes way
more sense and protects against subtly non-interoperable implementations
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings