This file is indexed.

/usr/share/perl5/Prima/gp-problems.pod is in libprima-perl 1.28-1.4.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
=for rcs $Id: gp-problems.pod,v 1.8 2007/09/13 15:12:25 dk Exp $

=head1 NAME 

Prima::gp-problems - Problems, questionable or intricate topics in 2-D Graphics

=head1 Introduction

One of the most important goals of the Prima project
is portability between different operating systems. Independently to
efforts in keeping Prima internal code that
it behaves more or less identically on different platforms, it is always possible
to write non-portable and platform-dependent code. 
Here are some guidelines and suggestions for 2-D graphics
programming.

=head1 Minimal display capabilities

A compliant display is expected to have minimal set
of capabilities, that programmer can rely upon. 
Following items are guaranteedly supported by Prima:

=over

=item Minimal capabilities

Distinct black and white colors

Line widths 0 and 1

One monospaced font

Solid fill

rop::Copy and rop::NoOper


=item Plotting primitives

SetPixel,GetPixel

Line,PolyLine,PolyLines

Ellipse,Arc,Chord,Sector

Rectangle

FillPoly

FillEllipse,FillChord,FillSector

TextOut

PutImage,GetImage

=item Information services

GetTextWidth,GetFontMetrics,GetCharacterABCWidths

GetImageBitsLayout

=item Properties

color

backColor

rop

backRop

lineWidth

lineJoin

lineStyle

fillPattern

fillPolyWinding

textOpaque

clipRect

All these properties must be present, however it is not
required for them to be changeable. Even if an underlying platform-specific code 
can only support one mode for a property, it have to follow all 
obligations for the mode. For example, if platform supports
full functionality for black color but limited functionality for the other colors,
the wrapping code should not allow color property to be writable then.

=back

=head1 Inevident issues 

=head2 Colors

=over

=item Black and white colors on paletted displays

Due the fact that paletted displays employ indexed color 
representation, 'black' and 'white' indices are not always
0 and 2^n-1, so result of raster image operations may look garbled (X).
Win32 and OS/2 protect themselves from this condition by 
forcing white to be the last color in the system palette.

Example: if white color on 8-bit display occupies palette index 15 
then desired masking effect wouldn't work 
for xoring transparent areas with cl::White.

Workaround: Use two special color constants
cl::Clear and cl::Set, that represent all zeros and all ones values
for bit-sensitive raster operations.

=item Black might be not 0, and white not 0xffffff

This inevident issue happens mostly on 15- and 16-bits
pixel displays. Internal color representation for the white color 
on a 15-color display ( assuming R,G and B are 5-bits fields) is 

 11111000 11111000 11111000
 --R----- --G----- --B-----

that equals to 0xf8f8f8. (All)

Advise: do not check for 'blackness' and 'whiteness'
merely by comparing a pixel value.

=item Pixel value coding

Status: internal

It is not checked how does Prima behave when a pixel value and 
a platform integer use different bit and/or byte priority (X).

=back

=head2 Filled shapes

=over

=item Dithering

If a non-solid pattern is
selected and a background and/or a foreground color
cannot be drawn as a solid, the correct rendering requires 
correspondingly 3 or 4 colors.  Some rendering engines (Win9X)
fail to produce correct results.

=item Overfill effect

In complex shapes ( FillPoly, for example) the platform renderer can
fill certain areas two or more times. Whereas the effect is not
noticeable with rop::CopyPut, the other raster operations
(like rop::Xor) produce incorrect picture. (OS/2)

NB - has nothing in common with the fill winding rule.

Workaround: Do not use raster operations with complex filled shapes

=item Pattern offset

For a widget that contains a pattern-filled shape, 
its picture will be always garbled after scrolling, 
because it is impossible to provide an algorithm
for a correct rendering without a prior knowledge of the
widget nature. (All)

Workaround: Do not use patterned backgrounds. 
Since the same effect is visible on dithered 
backgrounds, routine check for pure color might be applied.

=back

=head2 Lines

=over

=item Line caps over patterned styles

It is not clear, whether
gaps between dashes should be a multiple to a line width or
not. For example, lp::DotDot looks almost as a solid line when
lineWidth is over 10 if the first (non-multiple) tactic is chosen.
From the other hand it is hardly possible to predict the plotting 
strategy from a high-level code. The problem is related more to Prima 
design rather than to a platform-specific code. (All)

Workaround: use predefined patterns (lp::XXX) 

=item Line joins

Joint areas may be drawn two (or more) times -
the problem emerges if logical ROP (rop::Xor) is chosen.(OS/2)

=item Dithering

Dithering might be not used for line plotting. (Win9X)

=back

=head2 Fonts

=over

=item Font metric inconsistency

A font is loaded by request with one size,
but claims another afterwards.(OS/2, X).

Impact: system-dependent font description may not match
to Prima's.

Advise: do not try to deduce Prima font metrics from
system-dependent ones and vice versa.

=item Transparent plotting

No internal function for drawing transparent bitmaps (like fonts).
Therefore, if a font emulation is desired, special ROPs cannot be
reproduced. (OS/2, Win9X, WinNT)

Impact: font emulation is laborsome, primarily because the glyphs 
have to be plotted by consequential anding and xoring a bitmap.
Full spectrum of the raster operations cannot be achieved with this
approach.


=item Kerning

Prima do not use text kernings, nor
encourages underlying platform-specific code to use it - primarily
because of its complexity.
From the other hand, sometimes glyph position cannot be 
determined correctly if no information for the text kerning 
is provided. (Win9X) 

=item Fractional text position

If the font glyphs have fractional widths,
it might be observed that letters may change their position in
a string. 

Example: A set of glyphs has width of 8.6 pixels for each symbol.
If the string "abcd" is drawn at position 0,
then black part of "d" starts at 25th pixel, but if "cd" is drawn 
at 17th, as it supposed to be if the integer arithmetics is used, 
it starts at 24th pixel. (OS/2)

Solution: Do not rely to Drawable::get_text_width information,
because it always returns integer value, but to Drawable::get_font_abc,
which returns real values.

=item Text background

If a text is drawn with non-CopyPut raster operation, text background 
is not expected to be mixed with symbols - however this is hardly reachable,
so results differs for different platforms.

Text background may be only drawn with pure ( non-dithered ) color
(Win9X,WinNT) - but this is (arguably) a more correct behavior.

Advise: Do not use ::rop2 and text background for special effects

=item Internal platform features

Font change notification is not provided. (X, OS/2)

Raster fonts cannot be synthesized (OS/2, partly X)

=back

=head2 Raster operations ( ROPs)

Background raster operations are not supported (X,Win9X,WinNT) and
foreground ROPs have limited number of modes (OS/2,X). Not all ROPs
can be emulated for certain primitives, like fonts,
complex shapes, and patterned shapes.

It is yet unclear which primitives have to support ROPs, -
like FloodFill and SetPixel. Behavior of the current implementation 
is that they do not.


=head2 Arcs

Platforms tend to produce different results for 
angles outside 0 and 2pi. Although Prima assures that 
correct plotting would be performed for any angle,
minor inconsistencies may be noticed.
If emulating, note that 2 and 4-pi arcs
are not the same - for example, they look differently 
with rop::Xor.


=head2 Palettes

=over

=item Static palettes

Some displays are unable to change their hardware palette,
so detecting 8- or 4- bits display doesn't automatically mean that
palette is writable.(X)

=item Widget::palette

Widget::palette property is used for explicit declaration of extra 
color needs for a widget. The request might be satisfacted in different
ways, or might not at all. It is advisable not to rely onto platform
behavior for the palette operations.

=item Dynamic palette change

It is possible (usually on 8-bits displays) for a display to
change asynchronously its hardware palette in order to process 
different color requests. All platforms behave differently.

Win9X/WinNT - only one top-level window at a time 
and its direct children ( not ::clipOwner(0)) can benefit
from using Widget::palette. System palette is switched every time 
as different windows moved to the front.

OS/2 - not implemented, but in principle the same as under win32.

X - Any application can easily ruin system color table.
Since this behavior is such by design, no workaround can be
applied here.

=back

=head2 Bitmaps

=over

=item Invalid scaling

Scaling is invalid (Win9X) or not supported (X). Common mistake
is to not take into an account the fractional pixels that appear when
the scaling factor is more than 1. This mistake can be observed in Win9X.

Workaround: none

=item Large scale factors

Request for drawing a bitmap might fail 
if large scaling factor is selected. (OS/2,Win9X,WinNT).
This effect is obviously due that fact that these platforms
scale the bitmap into a memory before the plotting takes place.

=back

=head1 Platform-specific peculiarities

=head2 OS/2

Some ROPs are ambiguous - SRCTRANSPARENT, for example. Some
times they work, some times they don't. The particular behavior
depends on a video driver.

Circles cannot be drawn using an even diameter.

Fast GDI operations on HWND_DESKTOP may be delayed, thus
GetPixel may return invalid pixel values.


=head2 Windows 9X

Amount of GDI objects can not exceed some unknown
threshold - experiments show that 128 objects
is safe enough.

No transformations.

Color cursor creation routine is broken.

Filled shapes are broken.

=head2 X

No transformations

No bitmap scaling

No font rotation

No GetPixel, FloodFill ( along with some other primitives)

White is not 2^n-1 on n-bit paletted displays (tested on XFree86).

Filled shapes are broken.

Color bitmaps cannot be drawn onto mono bitmaps.

=head1 Implementation notes

=head2 OS/2

Palettes are not implemented

=head2 Win32

Plotting speed of DeviceBitmaps is somewhat less on 8-bit displays
than Images and Icons. It is because DeviceBitmaps are bound
to their original palette, so putting a DeviceBitmap onto
different palette drawable employs inefficient algorithms in
order to provide correct results.

=head2 X

Image that was first drawn on a paletted
Drawable always seen in 8 colors if drawn afterwards on a Drawable with the
different palette. That is because the image has special cache in display
pixel format, but cache refresh on every PutImage call is absolutely
inappropriate (although technically possible).
It is planned to fix the problem by checking
the palette difference for every PutImage invocation.
NB - the effect is seen on dynamic color displays only.

=head1 AUTHOR

Dmitry Karasik, E<lt>dmitry@karasik.eu.orgE<gt>.

=head1 SEE ALSO

L<Prima>