[gs-code-review] Fix : Improving the documentation about computing a text object tag in gspaint.c //. Fw: [gs-cvs] rev 7016 - trunk/gs/src

[Igor V. Melichev]

Folks,

In order of the codebase sanation I improved the comment
about computing object tags in gspaint.c how I understand it
from communicating with authors.
Please submit a patch or remarks if you find that
something is still wrong. Thank you.

Igor.

----- Original Message ----- 
From: <leonardo at ghostscript.com>
To: <gs-cvs at ghostscript.com>
Sent: Thursday, August 31, 2006 2:34 PM
Subject: [gs-cvs] rev 7016 - trunk/gs/src


> Author: leonardo
> Date: 2006-08-31 03:34:11 -0700 (Thu, 31 Aug 2006)
> New Revision: 7016
>
> Modified:
>   trunk/gs/src/gspaint.c
> Log:
> Fix : Improving the documentation about computing a text object tag in 
> gspaint.c .
>
> DETAILS :
>
> It's how I understand it while communicating with Stefan and Henry.
> I'll post it to code review for possible further improvements.
>
> EXPECTED DIFFERENCES :
>
> None.
>
>
> Modified: trunk/gs/src/gspaint.c
> ===================================================================
> --- trunk/gs/src/gspaint.c 2006-08-31 09:53:51 UTC (rev 7015)
> +++ trunk/gs/src/gspaint.c 2006-08-31 10:34:11 UTC (rev 7016)
> @@ -269,10 +269,33 @@
>  code = 0;
>     } else {
>  int abits, acode, rcode = 0;
> -        /* to distinguish text from vectors we hackly look at the
> -           target device 1 bit per component is a cache and this is
> -           text else it is a path */
>
> + /* Here we need to distinguish text from vectors to compute the object 
> tag.
> +    Actually we need to know whether this function is called to rasterize 
> a character,
> +    or to rasterize a vector graphics to the output device.
> +    Currently we assume it works for the bitrgbtags device only,
> +    which is a low level device with a 4-component color model.
> +    We use the fact that with printers a character is usually being 
> rendered
> +    to a 1bpp cache device rather than to the output device.
> +    Therefore we hackly look whether the target device
> +    "has a color" : either it's a multicomponent color model,
> +    or it is not gray (such as a yellow separation).
> +
> +    This check has several limitations :
> +    1. It doesn't work with -dNOCACHE.
> +    2. It doesn't work with large characters,
> +       which cannot fit into a cache cell and thus they
> +       render directly to the output device.
> +    3. It doesn't work for TextAlphaBits=2 or 4.
> +       We don't care of this case because
> +       text antialiasing usually usn't applied to printers.
> +    4. It doesn't work for things like with "(xyz) true charpath stroke".
> +       That's unfortunate, we'd like to improve someday.
> +    5. It doesn't work for high level devices when a Type 3 character is 
> being constructed.
> +       This case is not important for low level devices
> +       (which a printer is), because low level device doesn't accept
> +       Type 3 charproc streams immediately.
> + */
>         if (gx_device_has_color(gs_currentdevice(pgs))) {
>      gx_unset_dev_color(pgs);
>             gs_set_object_tag(pgs, GS_PATH_TAG);
>
> _______________________________________________
> gs-cvs mailing list
> gs-cvs at ghostscript.com
> http://www.ghostscript.com/mailman/listinfo/gs-cvs
>