This file is indexed.

/usr/share/doc/ghostscript-doc/Details.htm is in ghostscript-doc 9.18~dfsg~0-0ubuntu2.

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
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"   "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Ghostscript change history (detailed)</title>
<!-- generated by split_changelog.py from the output of cvs2cl.pl -->
<link rel=stylesheet type="text/css" href="gs.css">
</head>
<body>

<p><strong><a name="2011-03-28T084948.387061Z"></a>
2011-03-28T08:49:48.387061Z Chris Liddell</strong></p>
<blockquote>
<pre>
Reduce duplication of changelog and news by deprecating Changes.htm and
Details#.htm.

The information will now be in two places only: the highlights summary
in News.htm, and the detailed changes in History#.htm.

Update related documentation and html links to reflect this change.

CLUSTER_UNTESTED
</pre>
<p>[doc/Changes.htm doc/Readme.htm doc/Details9.htm doc/Release.htm]</p>
</blockquote>

<p><strong><a name="2011-03-26T145106.549590Z"></a>
2011-03-26T14:51:06.549590Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for issue found by Chris where we have a soft mask embedded in a softmask and graphic state pushes and pops occurring.  In this case, the soft mask stack that is saved gets out of sync compared to the one in the context state.    Use of the stack count can catch the issue and correct it.  Also a rename of one of the variables in the pdf14 code to make it easier to debug.</pre>
<p>[base/gdevp14.c base/gdevp14.h]</p>
</blockquote>

<p><strong><a name="2011-03-25T121205.657797Z"></a>
2011-03-25T12:12:05.657797Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Fixes concerning the compatibility of the OpenPrinting Vector (&quot;opvp&quot;)
output device with Ghostscript 9.x.

1. If there is any ICCColor based image in the PostScript input, GS crashes.
2. Fallback when path is too complex for some kinds of printers. This problem
   already existed in GS 8.x.

Thanks to Koji Otani from BBR Inc., Japan.

</pre>
<p>[contrib/opvp/gdevopvp.c]</p>
</blockquote>

<p><strong><a name="2011-03-25T102206.357287Z"></a>
2011-03-25T10:22:06.357287Z Chris Liddell</strong></p>
<blockquote>
<pre>
The code was erroneously attempting to get a glyph name for a case where
we already had a glyph index for a Truetype font.

Add a check for object type before trying to get a string from a name object.


Bug 692095

No cluster differences expected.

</pre>
<p>[psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2011-03-24T172617.397320Z"></a>
2011-03-24T17:26:17.397320Z Chris Liddell</strong></p>
<blockquote>
<pre>
Resolve build issues with language_switch and UFST.

I had (wrongly) assumed that the PCL/language_switch builds with UFST
and COMPILE_INITS=1 would have the relevant paths correctly setup for
the PS/PDF world to access the Microtype FCOs. It turns out they are
done in an incompatible manner.

So, I've renamed the path variables (in the makefiles) so there isn't
a clash between PCL and PS/PDF, ensured that the variables are correctly
passed through recursive (n)make calls, and tidied up the FAPI options
for the language_switch build.

Not only does this allow language_switch to build with the UFST, but the
Postscript interpreter does now use FAPI/UFST to access the Microtype fonts
for the built-in fonts, and uses FAPI/Freetype for downloaded fonts.

Bug 692093

No cluster differences expected.

</pre>
<p>[/trunk/ghostpdl/common/msvc_top.mak /trunk/ghostpdl/language_switch/pspcl6_msvc.mak /trunk/ghostpdl/main/pcl6_gcc.mak psi/msvc.mak base/Makefile.in psi/int.mak]</p>
</blockquote>

<p><strong><a name="2011-03-24T042223.459616Z"></a>
2011-03-24T04:22:23.459616Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for compiler warning.</pre>
<p>[base/gdevp14.h]</p>
</blockquote>

<p><strong><a name="2011-03-23T213420.429081Z"></a>
2011-03-23T21:34:20.429081Z Michael Vrhel</strong></p>
<blockquote>
<pre>
This commit fixes several issues.

Memory leaks in the PDF14 device as well as the separation devices.
Fixes in PDF14 device so the the color encoder and decoder are properly updated if soft masks occur with spot colors.
Proper copying of the devicen parameters to the clist devices in the MT rendering.  This was the source of a problem when doing multi-threaded rendering to separation devices.

This fixes bug 692087</pre>
<p>[base/gdevp14.c base/gsicc_cache.c base/gxclutil.c base/gdevpsd.c base/lib.mak base/gdevp14.h base/gxclthrd.c base/gdevtsep.c base/gdevdevn.c base/gxblend.c base/gdevdevn.h]</p>
</blockquote>

<p><strong><a name="2011-03-21T112417.021832Z"></a>
2011-03-21T11:24:17.021832Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for memory leaks in the pdf14 device.  These could occur with softmask and graphic state changes as well as when we are going to a tiffsep device.  </pre>
<p>[base/gdevp14.c]</p>
</blockquote>

<p><strong><a name="2011-03-20T014019.345427Z"></a>
2011-03-20T01:40:19.345427Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for bug 692087 crashes.   num_bytes - bytes_dropped was ending up negative in cases where the transparency device was reducing the number of colorants compared to the target device (mainly when we had a softmask) which was getting passed into the clist as an unsigned value.   Now when this occurs we just use the encoding of the full color value.  </pre>
<p>[base/gxclutil.c]</p>
</blockquote>

<p><strong><a name="2011-03-19T045652.259544Z"></a>
2011-03-19T04:56:52.259544Z Michael Vrhel</strong></p>
<blockquote>
<pre>
A temp fix for bugs 692038 and 692065.  The clist devices that are created for the threads now inherit the icc profile from the target device.  I need to set things up so that the device profile is no longer reference counted since we could have a race condition problem if the different threads are incrementing and decrementing the count and if the command is not atomic on a particular architecture.  The plan will be to no longer ref count the device profile but to have it maintained until the the actual target device is destroyed.  There will be a bit of work to do with respect to the pdf14 device, which can have a device profile that is different than the actual target device.  That profile can be altered with the transparency group pushes and pops.</pre>
<p>[base/gxclthrd.c]</p>
</blockquote>

<p><strong><a name="2011-03-19T003237.910024Z"></a>
2011-03-19T00:32:37.910024Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for some strange rendering with PDF 1.7 FTS files when we have shading and transparency
and are both filling and stroking text (Text Rendering modes 2 and 6). Customer 532.

</pre>
<p>[Resource/Init/pdf_ops.ps]</p>
</blockquote>

<p><strong><a name="2011-03-18T051608.669973Z"></a>
2011-03-18T05:16:08.669973Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix so that image_parent_type is properly initialized during clist image reading.</pre>
<p>[base/gsiparm4.h base/gximage1.c base/gximage4.c]</p>
</blockquote>

<p><strong><a name="2011-03-17T152458.552348Z"></a>
2011-03-17T15:24:58.552348Z Chris Liddell</strong></p>
<blockquote>
<pre>
Escape/quote the UFST path settings in the makefile so that the macros
correctly expand to strings.

Bug 692082

No cluster differences expected

CLUSTER_UNTESTED
</pre>
<p>[base/Makefile.in]</p>
</blockquote>

<p><strong><a name="2011-03-17T095453.062174Z"></a>
2011-03-17T09:54:53.062174Z Chris Liddell</strong></p>
<blockquote>
<pre>
Uncached glyphs were ignoring rendering mode 3, and being imaged
directly to the device - for cached glyphs the decision occurred
in the &quot;show machinery&quot;.

This wasn't my first choice solution, but all the others I tried
caused problems with later use of a cached glyph (which wasn't
actually cached), or problems with pdfwrite, pswrite or ps2write.


Bug 692004

No cluster differences expected.

</pre>
<p>[base/gspaint.c]</p>
</blockquote>

<p><strong><a name="2011-03-17T094116.074991Z"></a>
2011-03-17T09:41:16.074991Z Chris Liddell</strong></p>
<blockquote>
<pre>
Fix some issue where user specified devices didn't get the requisite &quot;&#36;(DD)&quot;
and &quot;.dev&quot; runes added to them.

Also, rearrange the &quot;pre-declared&quot; device strings to be more consistent within
configure.ac


Bug 692062

No cluster differences expected.


</pre>
<p>[base/configure.ac]</p>
</blockquote>

<p><strong><a name="2011-03-15T175917.340024Z"></a>
2011-03-15T17:59:17.340024Z Robin Watts</strong></p>
<blockquote>
<pre>
Add special case mem_planar_copy_color_4to1 code for copying bits
from 4 1 bit planes into 1 4 bit chunky plane.

This helps with performance of the plibk device.

No cluster differences expected.</pre>
<p>[base/gdevmpla.c]</p>
</blockquote>

<p><strong><a name="2011-03-15T083505.386182Z"></a>
2011-03-15T08:35:05.386182Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (ps2write) : Indexed colour images have incorrect /Decode

Bug #691924 &quot;Differences in colour with ps2write&quot;

The problem was due to the opdfread code generating a /Decode for an Indexed colour
space where the value was [0 2^n] and should be [0 ((2^n) - 1)]. This caused the
highest image sample to be mapped to 1 past the end of the samples in the colour space.

Normally this doesn't matter, because the values are clamped to 'hival' in the Indexed
space. In this case, however, the image was 2 bpp (4 values) but the colour space was
defined as a full 256 indices, with only the first 4 being used.

The incorrect Decode caused the image sample value 3 to be looked up as colour space
sample 4, which was set to all 0 (black) causing incorrect colour values.

</pre>
<p>[base/opdfread.h lib/opdfread.ps]</p>
</blockquote>

<p><strong><a name="2011-03-14T154615.599171Z"></a>
2011-03-14T15:46:15.599171Z Robin Watts</strong></p>
<blockquote>
<pre>
Reintroduce commented out PACIFY_VALGRIND definition in gximono.c - without it
the comment makes no sense.

Add new PACIFY_VALGRIND code (and commented out definition) in
gxht_threshold.c.

Fix some line endings.

No real code change, so no cluster differences expected.

</pre>
<p>[base/gximono.c base/gxht_thresh.c]</p>
</blockquote>

<p><strong><a name="2011-03-14T151608.036660Z"></a>
2011-03-14T15:16:08.036660Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix an indetermism in the halftoning code. When mapping a y offset into a
row index for a halftone tile, special care needs to be taken when y is
negative. Proof (as if more were needed) that the % operator in C is evil.

The command in question was a cutdown version of C306.bin rendered at 600bpi
to pbmraw with dMaxBitmap=10000.

It now runs into a clist UMR. Will keep looking.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-14T135351.702509Z"></a>
2011-03-14T13:53:51.702509Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (ps2write) : Don't set a default halftone.

Bug #691923 &quot;Differences in dithered output with ps2write&quot;

The PDF interpreter emits a setpagdevice between every page of output, in case the
media size has changed. The implementation of setpagedevice resets the halftone to be
the default halftone (106 lpi 45 degree line screen).

This is a problem for ps2write, and potantially pdfwrite, as there is no way to
differentiate between a default halftone set by setpagdevice, and a halftone contained
in the input file.

To avoid embedding an unhelpful halftone, we now check the device parameter
'/HighLevelDevice' in the setpagedevice implementation, and if it is present and true, 
we do not call .setdefaulthalftone.

Also updates documentation on device parameters.

This causes differences on every 1-bit rendering test (ie pkmraw) of the ps2write
output file, so approximately 1300 differences are to be expected.
</pre>
<p>[doc/Drivers.htm Resource/Init/gs_setpd.ps]</p>
</blockquote>

<p><strong><a name="2011-03-14T130003.503443Z"></a>
2011-03-14T13:00:03.503443Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix Bug 692064. Tiffscaled device was checking on page print time that the
expected size of the page wouldn't make the page too large to fit in a file.
This code was copied from the tiffgray device (as we render internally in
8bpp). As we output in monochrome however (and may use compression) the
test is in fact bogus, and should simply be removed. We do that here.

It's entirely possible that we should be removing the test from the
tiffgray device too - most systems with 32bit longs support large files these
days, and compression may apply here too anyway. I'll leave this until it
becomes an issue though.

No cluster differences expected.</pre>
<p>[base/gdevtsep.c]</p>
</blockquote>

<p><strong><a name="2011-03-13T115708.378919Z"></a>
2011-03-13T11:57:08.378919Z Ken Sharp</strong></p>
<blockquote>
<pre>
Some updates to the new device parameters. It turned out that the intended parameter
Type32ToUnicode was incorrectly implemented. This should actually have used the
WantsToUnicode parameter, because the code actually controls the processing of 
GlyphNames2Unicode tables from Windows PostScript.

This means we no longer need the Type32ToUnicode parameter and it has been removed.

Added initial documentation of these parameters.

This appears to cause some differences in Bug690829.ps rendered at 300 dpi. 
This is a surprise, because the changes should have no effect on devices other than
pdfwrite/ps2write, but the new result is better than the old, so this is a progression.
</pre>
<p>[Resource/Init/gs_pdfwr.ps base/gdevpdfx.h base/gdevpdfp.c doc/Drivers.htm base/gdevpdfb.h]</p>
</blockquote>

<p><strong><a name="2011-03-13T012149.785339Z"></a>
2011-03-13T01:21:49.785339Z Ray Johnston</strong></p>
<blockquote>
<pre>
Remove spurious debug printout inserted in rev 12141 line 780:
    1 index == 0 index ==
</pre>
<p>[Resource/Init/pdf_draw.ps]</p>
</blockquote>

<p><strong><a name="2011-03-11T192457.067395Z"></a>
2011-03-11T19:24:57.067395Z Ken Sharp</strong></p>
<blockquote>
<pre>
Change the default value for the 'AllowPSRepeat' so that it defaults to allowed instead
of disallowed (doh!) This is important for those devices which don't set the device
parameter.

No differences expected.
</pre>
<p>[psi/zfunc4.c]</p>
</blockquote>

<p><strong><a name="2011-03-11T171451.124213Z"></a>
2011-03-11T17:14:51.124213Z Ken Sharp</strong></p>
<blockquote>
<pre>
Remove a #if 0 accidentally left in the commit for revision 12282. Also initialise a
variable, just in case.

No differences expected.
</pre>
<p>[psi/zfunc4.c]</p>
</blockquote>

<p><strong><a name="2011-03-11T165834.690669Z"></a>
2011-03-11T16:58:34.690669Z Ken Sharp</strong></p>
<blockquote>
<pre>
The final removal of the reliance on testing the device name to influence interpreter
behaviour.

This tests the /AllowPSRepeat paramter and flags an error if a function tries to use 
'repeat' when it is disallowed.

Still to do: write some documentation on these new parameters.

No differences expected.
</pre>
<p>[psi/zfunc4.c]</p>
</blockquote>

<p><strong><a name="2011-03-11T151440.609962Z"></a>
2011-03-11T15:14:40.609962Z Chris Liddell</strong></p>
<blockquote>
<pre>
Add the new third party library directories to the Windows nmake zip file
target.

No cluster differences.

Bug 691944

Credit to: Gennadiy Tsarenkov.

CLUSTER_UNTESTED

</pre>
<p>[psi/winint.mak]</p>
</blockquote>

<p><strong><a name="2011-03-11T150756.095474Z"></a>
2011-03-11T15:07:56.095474Z Chris Liddell</strong></p>
<blockquote>
<pre>
Rejig the romfs targets so that unix make can follow the dependencies.

This should prevent the pointless rebuilding of the romfs C source.

Bug 692053

No cluster differences expected.

</pre>
<p>[base/lib.mak base/unix-aux.mak]</p>
</blockquote>

<p><strong><a name="2011-03-11T090424.536166Z"></a>
2011-03-11T09:04:24.536166Z Chris Liddell</strong></p>
<blockquote>
<pre>
Some (broken) TrueType fonts have out of order loca tables, which can result
in the calculated glyph data lengths being larger than the actual
available glyph data. Normally this does not cause a problem, but if the glyph
in question is in the final bytes of the stream, we encounter an unexpected
end of data condition when creating the glyph data buffer to pass into
Freetype.

So the FAPI interface code will now ignore that error, and adjust the byte
length to correctly reflect the number of bytes available in the buffer.

It is safe to do this because, in the event we have a genuine out-of-data
condition, Freetype will return an error when it tries to interpret the
glyph outline.

Bug 692043

No cluster differences expected.

</pre>
<p>[psi/fapi_ft.c psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2011-03-11T054519.450208Z"></a>
2011-03-11T05:45:19.450208Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Fix missing header problem on older versions of MSVC.
</pre>
<p>[base/gsropt.h]</p>
</blockquote>

<p><strong><a name="2011-03-11T041539.316030Z"></a>
2011-03-11T04:15:39.316030Z Michael Vrhel</strong></p>
<blockquote>
<pre>
A reorganization of the halftone code in preparation of doing thresholding of color images.  This basically pulls out some code pieces that will be shared in all the image thresholding cases.  No differences expected (or seen in the cluster push).</pre>
<p>[base/gxht_thresh.h base/lib.mak base/gximono.c base/gxicolor.c base/gxht_thresh.c]</p>
</blockquote>

<p><strong><a name="2011-03-10T173138.501799Z"></a>
2011-03-10T17:31:38.501799Z Robin Watts</strong></p>
<blockquote>
<pre>
I missed one change in commit 12274. The detection of chunky modes should
look at num_planes being &lt;= 1, not == 1.

I tested this locally and then clearly missed it when cluster pushing.
</pre>
<p>[base/gdevdrop.c]</p>
</blockquote>

<p><strong><a name="2011-03-10T165615.200283Z"></a>
2011-03-10T16:56:15.200283Z Robin Watts</strong></p>
<blockquote>
<pre>
Planar device is broken w.r.t rops in a cmyk space - this commit fixes it.

The planar memory device sets itself to use gx_default_strip_copy_rop
rather than mem_strip_copy_rop. mem_strip_copy_rop knows that rops on
cmyk pixels should actually convert to rgb, perform the rop, and convert
back again, but doesn't know how to convert the results back when it's in
planar mode. gs_default_strip_copy_rop can cope with planar mode, but doesn't
know to convert to rgb first.

The first fix included here is to extend mem_strip_copy_rop to know how to
write back to planar format, and then to make the planar memory device use
mem_strip_copy_rop.

This then exposes various flaws in mem_strip_copy_rop, including the fact
that it relies on being able to set the offset in get_bits calls when this
is sometimes not possible. We therefore fix the code to manage offsets
by explicitly updating them.

Also, the raster used in mem_strip_copy_rop was incorrect - we use the 
correct one and get much better results.

No cluster differences expected as the planar device is not tested.

</pre>
<p>[base/gdevdrop.c base/gdevmpla.c]</p>
</blockquote>

<p><strong><a name="2011-03-10T164220.394889Z"></a>
2011-03-10T16:42:20.394889Z Robin Watts</strong></p>
<blockquote>
<pre>
The routines in gdevplib.c intended to map colors in cmyk form back to rgb
were incorrect. Fixed here.

No differences expected as this files isn't linked in by default.

CLUSTER_UNTESTED


</pre>
<p>[base/gdevplib.c]</p>
</blockquote>

<p><strong><a name="2011-03-10T162704.913812Z"></a>
2011-03-10T16:27:04.913812Z Robin Watts</strong></p>
<blockquote>
<pre>
Remove the buffer blanking done in gximono.c. Previously removing this would
have caused indeterminisms. With the additional fix in here to limit
offset_bits to dest_width, however, we should get stable results.

This gives various differences in output (81 in pcl, presumably more in PDF
and PS). Bmpcmp of the pcl ones shows them as all progressions.

</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-10T145508.103488Z"></a>
2011-03-10T14:55:08.103488Z Ken Sharp</strong></p>
<blockquote>
<pre>
Update the remaining PostScript files (mostly the PDF interpreter) to use the new device
parameters instead of explicitly checking for the device being named 'pdfwrite' or 
'ps2write'.

Some more modification is still required, but we're nearly there. We will continue to 
check the device names in gs_pdfwr.ps when setting up the default state for those
specific devices.

Although not strictly a Distiller device, ps2write declares itself to be 'IsDistiller'. 
This is because some PostScript test files were found to behave differently if the 
distillerparams operators were available, in particular files would be oriented
differently if the device was deemed to be a Distiller.

</pre>
<p>[Resource/Init/gs_pdfwr.ps Resource/Init/pdf_font.ps Resource/Init/pdf_draw.ps base/gdevpdfb.h Resource/Init/gs_setpd.ps]</p>
</blockquote>

<p><strong><a name="2011-03-10T073145.990562Z"></a>
2011-03-10T07:31:45.990562Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Ignore null object when it is used instead of the gstate dictionary.
Bug 692050.
</pre>
<p>[Resource/Init/pdf_main.ps]</p>
</blockquote>

<p><strong><a name="2011-03-10T061917.004672Z"></a>
2011-03-10T06:19:17.004672Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Change all instances of true, false, and null to //true, //false, and //null
to avoid interferance from PS files that redefine them. Bug 692041.
</pre>
<p>[Resource/Init/gs_typ32.ps Resource/Init/gs_cidfm.ps Resource/Init/gs_mgl_e.ps Resource/Init/pdf_rbld.ps Resource/Init/gs_resmp.ps Resource/Init/gs_dscp.ps Resource/Init/gs_fonts.ps Resource/Init/gs_wan_e.ps Resource/Init/gs_mex_e.ps Resource/Init/gs_ttf.ps Resource/Init/gs_cspace.ps Resource/Init/gs_cff.ps Resource/Init/gs_dps1.ps Resource/Init/gs_lev2.ps Resource/Init/pdf_sec.ps Resource/Init/gs_l2img.ps Resource/Init/gs_cet.ps Resource/Init/gs_dbt_e.ps Resource/Init/gs_pdf_e.ps Resource/Init/gs_statd.ps Resource/Init/gs_fapi.ps Resource/Init/gs_pdfwr.ps Resource/Init/gs_cidfn.ps Resource/Init/pdf_main.ps Resource/Init/gs_dps.ps Resource/Init/gs_res.ps Resource/Init/gs_ll3.ps Resource/Init/gs_css_e.ps Resource/Init/gs_epsf.ps Resource/Init/pdf_draw.ps Resource/Init/gs_dpnxt.ps Resource/Init/gs_icc.ps Resource/Init/gs_mro_e.ps Resource/Init/pdf_ops.ps Resource/Init/gs_init.ps Resource/Init/pdf_font.ps Resource/Init/gs_ciddc.ps Resource/Init/gs_trap.ps Resource/Init/gs_cidtt.ps Resource/Init/gs_diskn.ps Resource/Init/gs_fntem.ps Resource/Init/pdf_base.ps Resource/Init/gs_sym_e.ps Resource/Init/gs_img.ps Resource/Init/gs_btokn.ps Resource/Init/gs_cidcm.ps]</p>
</blockquote>

<p><strong><a name="2011-03-10T005808.762234Z"></a>
2011-03-10T00:58:08.762234Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for bug 692038.

This fixes 3 issues when using a CIELAB based profile for the output device ICC profile.

One was a problem when handling separation color spaces when they had the ALL entry and we were going to an additive device.  AR does a 1-INK level for the device values and no color management.  We were doing the same, but this approach will not work if our destination color space is CIELAB.  Now if we are headed toward CIELAB we do the 1-INK to RGB and then transform to CIELAB. 

Another was that transparency blending should never be done in CIELAB or similar type color spaces.  With transparency, the PDF14 device inherits the profile for the target device and if the transparency groups don't specify a color space we would end up blending in CIELAB.  The solution was to detect this situation and use the defaultRGB profile for blending.  Conversion to CIELAB occurs during the pdf14 put image operation.  

Finally, with shading in transparency, we need to make sure to pass along the transparency device through the shading parameters whenever we have a color mismatch between the pdf14 device and the target device so that the shading will occur in the proper color space.

These changes are all related to a non-tested cluster case when we have -sOutputICCProfile=lab.icc</pre>
<p>[base/gdevp14.c base/gxcmap.c base/gstrans.c base/gxclist.h base/gdevtfnx.c base/gsfunc0.c base/devs.mak base/gsicc.c]</p>
</blockquote>

<p><strong><a name="2011-03-09T213258.461339Z"></a>
2011-03-09T21:32:58.461339Z Robin Watts</strong></p>
<blockquote>
<pre>
Add gxht_thresh.{c,h} to Visual C project.

CLUSTER_UNCHECKED</pre>
<p>[ghostscript.vcproj]</p>
</blockquote>

<p><strong><a name="2011-03-09T144440.068733Z"></a>
2011-03-09T14:44:40.068733Z Robin Watts</strong></p>
<blockquote>
<pre>
Disable PACIFY_VALGRIND in gximono.c. This define is intended to enable
extra code that can be performed so as to ensure that valgrind doesn't
report false positives. As such, disabling it should have no adverse
effects.

Unfortunately, it seems that in the portrait case, if we don't blank the
threshold array before we run, we get diffs. I have therefore taken this
memset out of the PACIFY_VALGRIND case and forced it to always happen.
This probably points to a bug and should be investigated properly.

No cluster differences expected.

</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-08T200017.821965Z"></a>
2011-03-08T20:00:17.821965Z Robin Watts</strong></p>
<blockquote>
<pre>
Simple optimisations to non SSE2 versions of halftoning code. There is
probably (certainly!) more performance to come with loop unrolling etc,
but this at least gets us the cheap win of avoiding repeated array accessing,
only setting, not blanking bits etc.

Cluster tests show no changes.

</pre>
<p>[base/gxht_thresh.c]</p>
</blockquote>

<p><strong><a name="2011-03-08T174051.077420Z"></a>
2011-03-08T17:40:51.077420Z Robin Watts</strong></p>
<blockquote>
<pre>
Change to gsroprun1.h to avoid over/underreading the source/texture buffers.

Given a valid byte range we expand that to the smallest enclosing CHUNK range
and guarantee never to access out of that range. Previously we could read
one CHUNK before/after it.

If this is a problem, simply ensure that CHUNK is byte rather than int on
your platform. This now behaves better than the original code which would
access one byte before/after the defined range.

No cluster differences seen in testing.

</pre>
<p>[base/gsroprun1.h]</p>
</blockquote>

<p><strong><a name="2011-03-08T163516.023687Z"></a>
2011-03-08T16:35:16.023687Z Tor Andersson</strong></p>
<blockquote>
<pre>
Add PNG reading support to the bmpcmp tool.</pre>
<p>[toolbin/bmpcmp.c]</p>
</blockquote>

<p><strong><a name="2011-03-08T151842.397978Z"></a>
2011-03-08T15:18:42.397978Z Ken Sharp</strong></p>
<blockquote>
<pre>
Update to use the new device parameter /PreserveTrMode instead of explicitly checking
for the device name being 'pdfwrite'.

No differences expected.
</pre>
<p>[Resource/Init/pdf_ops.ps]</p>
</blockquote>

<p><strong><a name="2011-03-08T082754.788378Z"></a>
2011-03-08T08:27:54.788378Z Ken Sharp</strong></p>
<blockquote>
<pre>
Activate the new device parameters, and modify the resource code to use the first one
(AllowIncrementalCFF) instead of testing for the pdfwrite device name.

No differences expected.
</pre>
<p>[Resource/Init/gs_cidfn.ps base/gdevpdfp.c]</p>
</blockquote>

<p><strong><a name="2011-03-08T002607.330315Z"></a>
2011-03-08T00:26:07.330315Z Robin Watts</strong></p>
<blockquote>
<pre>
When using PACIFY_VALGRIND, don't call the memory blanking when the
mallocs have failed.

This should cure the SEGVs that were introduced, but otherwise cause no
changes.

</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T221929.253652Z"></a>
2011-03-07T22:19:29.253652Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Initialize ht landscape structure to zero when in portrait case.  There is a conditional test on the value later.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T215702.879011Z"></a>
2011-03-07T21:57:02.879011Z Robin Watts</strong></p>
<blockquote>
<pre>
Correct line endings (were DOS, should be Unix).

No cluster differences.

CLUSTER_UNTESTED

</pre>
<p>[base/gxht_thresh.h base/gxht_thresh.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T211712.494498Z"></a>
2011-03-07T21:17:12.494498Z Robin Watts</strong></p>
<blockquote>
<pre>
Add new debugging define to gximono.c, PACIFY_VALGRIND.

This enables various small tweaks in the code that stop valgrind throwing
errors. We believe that all the errors thrown are false positives, but
we enable this define anyway until we've sorted the current indeterminisms.
We'll disable it in a few days when we have solved the problems and check that
it really doesn't cause any more.

Cluster results unknown; probably no change. If this solves indetermisms
then we'll need to understand why.

</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T211156.916525Z"></a>
2011-03-07T21:11:56.916525Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix typos, one in a comment, one in an id string.

No cluster differences.

CLUSTER_UNTESTED

</pre>
<p>[base/gxipixel.c base/gzspotan.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T185808.149818Z"></a>
2011-03-07T18:58:08.149818Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for improper indexing of reversed portrait image line.  We were off by one byte and ended up with one byte not set.  Def. a source of indeterminism.  Thanks to Robin for tracking this down.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T154013.201330Z"></a>
2011-03-07T15:40:13.201330Z Ken Sharp</strong></p>
<blockquote>
<pre>
Undo revision 12243. The revision makes a debug print dependent on the value of the
 'size_set' variable. Unfortunately, this variable is not defined in the cups_get_matrix
routine. It is defined in the other places it is used (cups_put_params).

This prevents a debug build from compiling on Windows, and I can't see how it would
work on any other OS when built for debug.

Reverted the change in order to build debug versions of Ghostscript.
</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T142111.345196Z"></a>
2011-03-07T14:21:11.345196Z Ken Sharp</strong></p>
<blockquote>
<pre>
Redo revision 12248 in a way which (hopefully!) doesn't cause seg faults.

Still no differences expected....
</pre>
<p>[base/gdevpdfx.h base/gdevpdfp.c base/gdevpdfb.h]</p>
</blockquote>

<p><strong><a name="2011-03-07T124047.052280Z"></a>
2011-03-07T12:40:47.052280Z Chris Liddell</strong></p>
<blockquote>
<pre>
Account for fonts in which (some) charstrings have been replaced with
Postscript procedures when FAPI decides an outline, or just a width
is required. The previous code only handled this case for rendered
glyphs from Freetype.

Bug 692029

No cluster differences expected.



</pre>
<p>[psi/zfapi.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T111219.973357Z"></a>
2011-03-07T11:12:19.973357Z Ken Sharp</strong></p>
<blockquote>
<pre>
pdfwrite &amp; ps2write enhancement

Add some new keys to the device parameters dictionary for these devices. These will be
used to replace the explicit tests against the device name in various places in future
commits.

These will also later be documented and their use suggested for any devices requiring
the same capabilities.

No differences expected, these are not used yet.</pre>
<p>[base/gdevpdfp.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T094302.986503Z"></a>
2011-03-07T09:43:02.986503Z Chris Liddell</strong></p>
<blockquote>
<pre>
Update the second place where we may have to reset the Freetype glyph object.

Again, this means we only free the outline or bitmap data, and just let
Freetype &quot;reset&quot; its glyph object between glyphs.

No cluster differences expected.

</pre>
<p>[psi/fapi_ft.c]</p>
</blockquote>

<p><strong><a name="2011-03-07T070812.439689Z"></a>
2011-03-07T07:08:12.439689Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for compositor device chaining in the pdf14 device. This was detected in a
file that did overprint along with transparency. The pdf14 device incremented the
ref_count for the overprint_device, but never decremented it since the 'finalize'
of the pdf14 device was left at NULL rather than being set to the gx_forward_finalize
function which should be used. The gx_device_set_target, rather than rc_assign does
the proper set of the finalize proc pointer so that reference counts for the device
chain are properly maintained. Detected by customer 532 since their device freed
the clist buf_device resulting in the overprint_device having a 'target' pointer
to freed memory, causing a SEGV when the 'finalize' function executed.

No regressions expected since in the normal code, the GC frees the devices that
were left unreferenced by the free of the pdf14 device.
</pre>
<p>[base/gdevp14.c]</p>
</blockquote>

<p><strong><a name="2011-03-06T165219.765042Z"></a>
2011-03-06T16:52:19.765042Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix to use proper DDA incrementation for interpolation.  We still maintain special loops for when there is no scaling or for when it is 2x.  This should fix the intdeterminism issues.   Tested performance on customer files and no significant difference was observed.   About 1500 cluster differences will be reported with this fix.</pre>
<p>[base/lib.mak base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-06T111548.120325Z"></a>
2011-03-06T11:15:48.120325Z Chris Liddell</strong></p>
<blockquote>
<pre>
Instead of destroying and recreating freetype's glyph object for every glyph
we need to render, we can just free the &quot;transient&quot; parts: the bitmap or the
outline.

Saves a very small amount of time, and potentially reduces memory pool
fragmentation.

No cluster differences expected.

</pre>
<p>[psi/fapi_ft.c]</p>
</blockquote>

<p><strong><a name="2011-03-05T174646.608714Z"></a>
2011-03-05T17:46:46.608714Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Do not do debug output of an uninitialized variable

Thanks to Richard Hughes (hughsient at gmail dot com) for the patch.

</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2011-03-04T192750.114304Z"></a>
2011-03-04T19:27:50.114304Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Correction on Richard Hughes' patch for color management in the CUPS filters.
</pre>
<p>[cups/colord.c]</p>
</blockquote>

<p><strong><a name="2011-03-04T175100.067911Z"></a>
2011-03-04T17:51:00.067911Z Henry Stiles</strong></p>
<blockquote>
<pre>
Fix a warning and type error.  Code should produce the same results,
so no testing.

CLUSTER_UNTESTED

</pre>
<p>[base/gdevdgbr.c]</p>
</blockquote>

<p><strong><a name="2011-03-04T133411.568425Z"></a>
2011-03-04T13:34:11.568425Z Robin Watts</strong></p>
<blockquote>
<pre>
Add FIXME to gximono.c about possible future optimisation, so it is not
forgotten.

CLUSTER_UNTESTED

</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-04T093504.845642Z"></a>
2011-03-04T09:35:04.845642Z Chris Liddell</strong></p>
<blockquote>
<pre>
Only attempt to create files in the &quot;cups&quot; directory if it exists.
</pre>
<p>[base/configure.ac]</p>
</blockquote>

<p><strong><a name="2011-03-04T064529.360251Z"></a>
2011-03-04T06:45:29.360251Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Reorganization of threshold code to move all the thresh holding operations into a new file. </pre>
<p>[base/gxht_thresh.h base/lib.mak base/gximono.c base/gximage.h base/gxht_thresh.c base/gsiparam.h]</p>
</blockquote>

<p><strong><a name="2011-03-04T061653.560659Z"></a>
2011-03-04T06:16:53.560659Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Add missing test for /packedarraytype during recursive dereferencing
of composite PDF objects. Bug 692018, customer 850.
</pre>
<p>[Resource/Init/pdf_base.ps]</p>
</blockquote>

<p><strong><a name="2011-03-03T222022.363870Z"></a>
2011-03-03T22:20:22.363870Z Henry Stiles</strong></p>
<blockquote>
<pre>
The get_bits() device call was assumed to return copied data and fill
in the allocated memory pointed to by the variable row, in fact the
gets_bit call can also just return a pointer and row is never
initialized, now we detect that.  This broke raster operations for the
display device and appears to have resulted in the use of
uninitialized data in other files.  A sampling of changed files showed
single pixel differences in files.

</pre>
<p>[base/gdevdgbr.c]</p>
</blockquote>

<p><strong><a name="2011-03-03T202923.683592Z"></a>
2011-03-03T20:29:23.683592Z Robin Watts</strong></p>
<blockquote>
<pre>
Update plibc and plibk to output pams when built with DEBUG_DUMP.

No cluster differences possible as this code is not used in cluster testing.

CLUSTER_UNTESTED</pre>
<p>[base/gdevplib.c]</p>
</blockquote>

<p><strong><a name="2011-03-03T202343.920044Z"></a>
2011-03-03T20:23:43.920044Z Robin Watts</strong></p>
<blockquote>
<pre>
Add new pamcmyk4 device. Identical to pamcmyk32 device, but works in 1 bit
per component, rather than 8.

No cluster differences expected as this code isn't tested.</pre>
<p>[psi/msvc.mak base/unix-gcc.mak base/gdevpbm.c base/devs.mak]</p>
</blockquote>

<p><strong><a name="2011-03-03T175148.590954Z"></a>
2011-03-03T17:51:48.590954Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Enabling of thresholding code as default image rendering of monochrome/indexed images for monochrome devices.  This will result in about 2432 differences reported.  I stepped through them in a bmpcmp to check for serious issues.  The minor halftone differences were due to the fact that we step in the device space for pixel replication in the threshold code but step in source space for the rect fill code.  Enabling this code now will make it easier to track issues as we expand the use of the thresholding code.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-03-03T154846.192376Z"></a>
2011-03-03T15:48:46.192376Z Robin Watts</strong></p>
<blockquote>
<pre>
Add plib device (c and h) files to ghostscript project file.

No cluster differences expected as project file is not used by cluster.

CLUSTER_UNTESTED</pre>
<p>[ghostscript.vcproj]</p>
</blockquote>

<p><strong><a name="2011-03-03T000827.251299Z"></a>
2011-03-03T00:08:27.251299Z Marcos H. Woehrmann</strong></p>
<blockquote>
<pre>
Added the ability to specify bmpcmp in addition to a normal clusterpush.pl
operation.  Both commands will be queued in the correct order.

Examples:

  ./clusterpush.pl gs bmpcmp
  ./clusterpush.pl bmpcmp gs pcl xps ls

Note that the order of the options is not signficant.

The command line parser for clusterpush.pl changed signficantly with this
revision.  It should be backwards compatible with the previous version
but it's possible that subtle differences exist.  If a clusterpush.pl
command line behaves differently than you expect please open a bug.

</pre>
<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/clusterpush.pl toolbin/localcluster/clusterpush.txt]</p>
</blockquote>

<p><strong><a name="2011-03-02T221239.208205Z"></a>
2011-03-02T22:12:39.208205Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix rop operation on plib device. Previously, I'd disabled get_bits_rectangle
on the buffer device as the data is normally in the format we need it in
anyway, so it's a NOP. Unfortunately it's needed for rop operation, so
reintroduce it.

To avoid infinite loops, we have to cope with GB_RETURN_POINTER. This is
easy to add to the gdevmpla.c device, but it's less clear that adding it
into the mem device is the right thing to do. We therefore introduce a
shim function to cope with GB_RETURN_POINTER with the mem device.

No cluster differences expected as this is disabled by default.

Testing shows that the planar device is now very close to the non planar
equivalent.</pre>
<p>[base/gdevplib.c base/gdevmpla.c]</p>
</blockquote>

<p><strong><a name="2011-03-02T205046.635530Z"></a>
2011-03-02T20:50:46.635530Z regression</strong></p>
<blockquote>
<pre>
Minor bug fixes and improvements to the cluster system, the most
signifcant of which is the addition of &quot;CLUSTER_UNTESTED&quot; detection.
If this keyword appears anywhere within the log message of a commit that
revision will not be tested by the cluster.

Less interesting changes include:

  Fix for bmpcmp if large numbers of differences are produced

  Addition of 'svn cleanup' calls before 'svn update' to handle nodes that
  crashed during previous 'svn update' and left the repositories locked

  Set status of all nodes to idle after jobs are completed.

  Fix bugs that caused bmpcmp completed emails to be appended to the
  previous message.

</pre>
<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/pngs2html.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl]</p>
</blockquote>

<p><strong><a name="2011-03-02T185123.645025Z"></a>
2011-03-02T18:51:23.645025Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Introduction of a member variable in gs_image1_t, which will let us know the original source type of the image.  For example if, the parent source were type3 this spawns two type1 images.  One for the mask and one for the image data.  The mask is rendered using image render simple.  If the image is monochrome or indexed, it is rendered with the renderer in gximono.c .   If we are going to a halftone monochrome device, we end up using the fast threshold based renderer which has its interpolation stepping in device space as opposed to source space.  This causes very minor differences between the mask and the image data.  To avoid this, we use the old rect_fill code for the image type3 data to ensure a more exact spatial match.</pre>
<p>[base/gximono.c base/gximage1.c base/gximage2.c base/gximage3.c base/gximage4.c base/gximage.h base/gximag3x.c base/gsiparam.h]</p>
</blockquote>

<p><strong><a name="2011-03-02T133952.433442Z"></a>
2011-03-02T13:39:52.433442Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix bmpcmp bug; the map array was being incorrectly sized, resulting in
occasional memory corruption.

No cluster differences expected.</pre>
<p>[toolbin/bmpcmp.c]</p>
</blockquote>

<p><strong><a name="2011-03-02T000925.760114Z"></a>
2011-03-02T00:09:25.760114Z Robin Watts</strong></p>
<blockquote>
<pre>
Debug output for gdevplibm (monochrome planar interlaced bands) was broken
and writing malformed pbms. Simple fix - move the mono output code to the
mono branch of the if rather than the grey one.

No cluster differences expected.</pre>
<p>[base/gdevplib.c]</p>
</blockquote>

<p><strong><a name="2011-03-01T193056.622647Z"></a>
2011-03-01T19:30:56.622647Z Robin Watts</strong></p>
<blockquote>
<pre>
Remove DOS line endings from .gitignore files.</pre>
<p>[.gitignore /trunk/ghostpdl/.gitignore]</p>
</blockquote>

<p><strong><a name="2011-03-01T171830.158752Z"></a>
2011-03-01T17:18:30.158752Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for error introduced in non-SSE2 code when I removed the inclusion of the transfer function into the threshold values.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-02-28T223128.419926Z"></a>
2011-02-28T22:31:28.419926Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Added color management support to the CUPS ...toraster filters

Replaced the ...toraster filters by one filter executable, gstoraster,
written in C. This filter converts both PostScript and PDF input into
the CUPS Raster format using Ghostscript with the &quot;cups&quot; output
device, controlled by settings in the print queue's PPD file, by
command line options, and by settings embedded in a PostScript input
stream. This is now done with color management based on
printer-specific ICC profiles referenced in the PPD file or supplied
by the color management daemon colord. The CUPS PPD extensions
concerning color management
(http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html) are made
use of if used and the colord daemon is used if it is present. colord
is accessed via D-Bus, but the new filter can also be compiled without
D-Bus and in this case only the CUPS PPD extensions and ICC profiles
assigned to the print queue are used for color management.

Thanks to Richard Hughes for the patch.

</pre>
<p>[cups/pstoraster.in cups/pstoraster.convs cups/gstoraster.c cups/pdftoraster.c cups/cups.mak base/Makefile.in cups/colord.c base/configure.ac cups/gstoraster.convs cups/pdftoraster.convs cups/colord.h]</p>
</blockquote>

<p><strong><a name="2011-02-28T203043.994348Z"></a>
2011-02-28T20:30:43.994348Z Robin Watts</strong></p>
<blockquote>
<pre>
X offset in custom 24 -&gt; 888 planar copy_color routine was being miscalculated.
Simple fix.

No cluster differences expected as this is untested.</pre>
<p>[base/gdevmpla.c]</p>
</blockquote>

<p><strong><a name="2011-02-28T193534.539587Z"></a>
2011-02-28T19:35:34.539587Z Robin Watts</strong></p>
<blockquote>
<pre>
Remove silly debugging hack left in gdevmpla.c by accident. Only affects
planar 888 devices (i.e. none enabled by default).

No cluster differences expected.</pre>
<p>[base/gdevmpla.c]</p>
</blockquote>

<p><strong><a name="2011-02-28T193237.270892Z"></a>
2011-02-28T19:32:37.270892Z Robin Watts</strong></p>
<blockquote>
<pre>
Add simple .gitignore files.</pre>
<p>[.gitignore /trunk/ghostpdl/.gitignore]</p>
</blockquote>

<p><strong><a name="2011-02-28T104811.852106Z"></a>
2011-02-28T10:48:11.852106Z Ken Sharp</strong></p>
<blockquote>
<pre>
Silence a compiler (scan-build) warning about a variable never being used.</pre>
<p>[base/gdevpdfo.c]</p>
</blockquote>

<p><strong><a name="2011-02-28T052346.157854Z"></a>
2011-02-28T05:23:46.157854Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for mis-scale on decode for render mono cache.  Fixes improper rendering of 148-11.ps with new halftone code.</pre>
<p>[base/gxipixel.c]</p>
</blockquote>

<p><strong><a name="2011-02-27T232610.406657Z"></a>
2011-02-27T23:26:10.406657Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Removal (or inactivation) of code to include inverse of transfer function in the threshold values.  Also minor fix for scaling issue in halftone code in portrait mode.  Code is inactive so no regression diffs expected.</pre>
<p>[base/gximono.c base/gsht.c]</p>
</blockquote>

<p><strong><a name="2011-02-27T232330.287293Z"></a>
2011-02-27T23:23:30.287293Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix for a bug that was introduced with the ICC branch.  This was causing a mismatch between banded an unbanded rendering and in particular had rendering errors in banded mode when rendering PS and PDF files that had a non identity transfer function.  Minor progression diffs in many files with very visible progressions in 246-01.ps, 258-01.ps as examples.  What was happening is that when running in clist mode, we were not recognizing that a transfer function was present when doing the ICC branch.  Stumble upon this working the transfer function in with the new threshold based halftoning code.</pre>
<p>[base/gxipixel.c]</p>
</blockquote>

<p><strong><a name="2011-02-27T015228.834714Z"></a>
2011-02-27T01:52:28.834714Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for PDF with ASCII85Decode filter that has a dictionary (even if empty)
instead of a 'null' for the params. Stack has the param dict second on the
stack, not third. Bug 692003, customer 700.
</pre>
<p>[Resource/Init/pdf_base.ps]</p>
</blockquote>

<p><strong><a name="2011-02-26T191752.838303Z"></a>
2011-02-26T19:17:52.838303Z Till Kamppeter</strong></p>
<blockquote>
<pre>
TCUPS Raster driver: The macros in the cups_put_params() function
could access uninitialized variables when logging error messages and
this could lead to a segmentation fault, making Ghostscript crashing
and many jobs not printed. Debian bug #615202.

</pre>
<p>[cups/gdevcups.c]</p>
</blockquote>

<p><strong><a name="2011-02-26T184059.351498Z"></a>
2011-02-26T18:40:59.351498Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for PDF 1.7 fts_08_0808.pdf which can clip the corner of the really wide
diagonal (magenta) stroke when banding is used. This was due to the 'extension'
of a square line cap being incorrectly calculated. Customer 532 issue.
</pre>
<p>[base/gxstroke.c]</p>
</blockquote>

<p><strong><a name="2011-02-26T182508.170267Z"></a>
2011-02-26T18:25:08.170267Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix BUILD_SYSTEM conditional for 64 vs. 32 and add 'for Win64' message
to help avoid confusion during setup.
</pre>
<p>[psi/winint.mak]</p>
</blockquote>

<p><strong><a name="2011-02-25T235750.833144Z"></a>
2011-02-25T23:57:50.833144Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix bug reported by &quot;new customer feb 2011&quot;, whereby gs 8.71 on an embedded
ppc platform is getting the colours on an image in a pdf wrong.

Debugging shows that in gs_indexed_limit_and_lookup we take a floating point
value, clip it, convert it to an int and use it to lookup which colour to use.
On the reference x86 run we have a value of 1 (0x3f800000 as an IEEE float).
On the ppc we have 0.999999 (0x3f7fffff as an IEEE float). This tiny difference
results in values of 1 and 0 respectively when converted to the int, giving
the wrong colour.

The fix here is to add a small epsilon before conversion.

A quick experiment in adding 0.5 rather than epsilon shows worse results.

15 cluster differences in testing, none that actually survived a bmpcmp.


</pre>
<p>[base/gscolor2.c]</p>
</blockquote>

<p><strong><a name="2011-02-25T194939.160812Z"></a>
2011-02-25T19:49:39.160812Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Fix so that we only do the fast code if we are in portrait or landscape mode.  Skewed objects will have to use the rect fill method.</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-02-25T193355.727547Z"></a>
2011-02-25T19:33:55.727547Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Addition of code to incorporate the inverse of the transfer curve into the threshold matrix.  If the curve is an inverting type (e.g. 0 to 1 and 1 to 0) then a the thresholding comparison is switched.  Also, if the curve is not monotonic, it can not be inverted and we revert to the old rect fill method.  This commit has the code disabled so there should not be any regressions.</pre>
<p>[base/lib.mak base/gximono.c base/gzht.h base/gxdht.h base/gsht.c]</p>
</blockquote>

<p><strong><a name="2011-02-25T181349.002375Z"></a>
2011-02-25T18:13:49.002375Z Ray Johnston</strong></p>
<blockquote>
<pre>
Set the GS_DLL to gsdll64.dll for a 64-bit build. The file list was correct,
but the registry was not. Related to bug 691975 but not verified (I just
checked the registry using regedit).
</pre>
<p>[psi/dwsetup.cpp]</p>
</blockquote>

<p><strong><a name="2011-02-25T074221.024741Z"></a>
2011-02-25T07:42:21.024741Z Chris Liddell</strong></p>
<blockquote>
<pre>
Revise how the UFST setting are handled in the makefiles.

The previous version relied on GNU make extensions (specifically
conditionals), whilst this version does not.

No cluster differences expected.

</pre>
<p>[base/lib.mak psi/msvc.mak base/Makefile.in psi/int.mak]</p>
</blockquote>

<p><strong><a name="2011-02-24T111312.751072Z"></a>
2011-02-24T11:13:12.751072Z Chris Liddell</strong></p>
<blockquote>
<pre>
Hopefully the final iteration of allowing SHARE_ZLIB
to work correctly with COMPILE_INITS=1.

This version changes only Unix-like builds, so Windows need
not suffer, and also removes the reliance GNU make specific
extensions.

Bug 691986
	

No cluster differences.

</pre>
<p>[base/unix-aux.mak]</p>
</blockquote>

<p><strong><a name="2011-02-24T005108.210054Z"></a>
2011-02-24T00:51:08.210054Z Robin Watts</strong></p>
<blockquote>
<pre>
Add new plib family of devices (PLanar Interlaced Buffer). These 5 devices
(plib = r8g8b8, plibg = g8, plibm = mono, plibc = c8m8y8k8, plibk = c1m1y1k1)
use a new 'band donor' interface to request a band buffer, pass back
rendered bands, and release bands at the end of the page.

The idea is that other firmware can implement this simple interface, and
Ghostscript can thus easily drive systems that expect planar interlaced
input.

On the whole there is relatively little new code here; the majority of the
work is done using the existing planar device with the odd tweak here and
there. Firstly, we lift the (artifical) constraints of the number of components
supported (so greyscale is accepted as a planar device for simplicity).
We spot the num_components = 1 case and just use the existing memory device
interface.

Secondly, we add a fast 888chunky to 888planar unpacking routine for use
with copy_color.

Within the plib device itself, we make use of the facility to set the line
indexes to allow for interlaced operation. It would be easy to extend this
device to offer planar non-interlaced operation too built on the same band
donor interface simply by omitting this code.

For debugging purposes we have options within the plib devices to store the
data returned in each band into pxm files (as appropriate to the number of
components). This code is deactivated by default as the output of this
device is via the band donor interface, not the output file.

No cluster differences expected as this code is disabled currently.

Next job: discuss with Marcos how to cluster test this.

</pre>
<p>[base/gdevplib.c base/gdevmpla.c base/gdevplib.h base/gdevppla.c base/devs.mak]</p>
</blockquote>

<p><strong><a name="2011-02-23T160025.505362Z"></a>
2011-02-23T16:00:25.505362Z Robin Watts</strong></p>
<blockquote>
<pre>
Introduce and enable 8 bit rop run templated code.

No cluster differences shown.

</pre>
<p>[base/gsroprun8.h base/lib.mak base/gsroprun.c ghostscript.vcproj]</p>
</blockquote>

<p><strong><a name="2011-02-23T144145.053687Z"></a>
2011-02-23T14:41:45.053687Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Remove commented out code left over from commit 12192</pre>
<p>[base/lib.mak]</p>
</blockquote>

<p><strong><a name="2011-02-23T115400.145784Z"></a>
2011-02-23T11:54:00.145784Z Robin Watts</strong></p>
<blockquote>
<pre>
Reintroduce runrop changes to Visual Studio solution lost in recent merge
(r12189).

No cluster differences expected.

</pre>
<p>[ghostscript.vcproj]</p>
</blockquote>

<p><strong><a name="2011-02-23T082540.039813Z"></a>
2011-02-23T08:25:40.039813Z Chris Liddell</strong></p>
<blockquote>
<pre>
Revision to the changes for using the system zlib.

r12184 caused problems on Windows. 

This approach uses configure to determine whether
freetype should use the system zlib, based on whether
Ghostscript is using the system zlib.

Windows, of course, doesn't use configure, so it will
never attempt to the use the system zlib.

Bug 691986

No cluster differences expected

</pre>
<p>[base/freetype.mak base/Makefile.in base/configure.ac]</p>
</blockquote>

<p><strong><a name="2011-02-23T032618.063337Z"></a>
2011-02-23T03:26:18.063337Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Temporary fix to turn off fast code for cases where the bps of the index image is not 8bps</pre>
<p>[base/gximono.c]</p>
</blockquote>

<p><strong><a name="2011-02-23T010908.645858Z"></a>
2011-02-23T01:09:08.645858Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Undo of rev 12184 by commenting out the changes for now.  This change broke the windows build.  </pre>
<p>[base/lib.mak]</p>
</blockquote>

<p><strong><a name="2011-02-22T213158.870907Z"></a>
2011-02-22T21:31:58.870907Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix warnings caused by merging the halftone branch to the trunk in r12189.

No cluster differences expected.

</pre>
<p>[base/gxipixel.c base/gximono.c base/gsht.c]</p>
</blockquote>

<p><strong><a name="2011-02-22T200337.651092Z"></a>
2011-02-22T20:03:37.651092Z Robin Watts</strong></p>
<blockquote>
<pre>
Forgot this file inthe last commit. Sorry!

</pre>
<p>[base/gsroprun24.h]</p>
</blockquote>

<p><strong><a name="2011-02-22T195243.275685Z"></a>
2011-02-22T19:52:43.275685Z Michael Vrhel</strong></p>
<blockquote>
<pre>
Merge of halftone branch into the trunk.  The new rendering code is actually disabled with this commit.  As such, there should not be any testing differences.</pre>
<p>[base/gxipixel.c base/lib.mak base/Makefile.in base/gxcie.h /trunk/gs base/gsht.c base/gxcmap.c psi/msvc.mak ghostscript.vcproj base/gximono.c base/gzht.h base/gxidata.c base/configure.ac base/gxdht.h base/gxcmap.h base/gxicolor.c base/gximage.h base/gsciemap.c]</p>
</blockquote>

<p><strong><a name="2011-02-22T193857.296889Z"></a>
2011-02-22T19:38:57.296889Z Robin Watts</strong></p>
<blockquote>
<pre>
Add templated 24bit rops. Clusterpushing seems to indicate this works.

No cluster differences expected.

</pre>
<p>[base/lib.mak base/gsroprun.c base/gsroprun1.h]</p>
</blockquote>

<p><strong><a name="2011-02-22T161008.900201Z"></a>
2011-02-22T16:10:08.900201Z Chris Liddell</strong></p>
<blockquote>
<pre>
Tweak to allow compressed romfs to be built when we're configured
to use the system's zlib rather than our own.

As a side effect of this, freetype is now configured to use the
same zlib instance as Ghostscript (instead of freetype's own
subset of zlib sources).

Bug 691986

No cluster differences expected.

</pre>
<p>[base/freetype.mak base/lib.mak]</p>
</blockquote>

<p><strong><a name="2011-02-22T154409.440053Z"></a>
2011-02-22T15:44:09.440053Z Robin Watts</strong></p>
<blockquote>
<pre>
Add new gsroprun files to Visual Studio solution.

No cluster differences expected.

</pre>
<p>[ghostscript.vcproj]</p>
</blockquote>

<p><strong><a name="2011-02-22T152803.132855Z"></a>
2011-02-22T15:28:03.132855Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix DO_FILL_RECT_BY_COPY_ROP code, and enable it by default.

The only thing wrong with the code before is the case when strip_tile_rectangle
is called with both color0 and color1 being gx_no_color_index. That translates
to rop=0xAA (i.e. D - no change). This is actually a special case that means
it's really doing a copy_color operation. We handle this by punting in the
same way as the old code used to.

No cluster differences expected.

</pre>
<p>[base/gdevm1.c]</p>
</blockquote>

<p><strong><a name="2011-02-22T001816.845591Z"></a>
2011-02-22T00:18:16.845591Z Robin Watts</strong></p>
<blockquote>
<pre>
Enable mono_copy_mono implemented in terms of mono_copy_rop.

Very small changes to the code to ensure that the copied area is correctly
clipped, this now gives identical results to the existing code, but should
be faster.

The tile_rectangle code is still misbehaving - will fix this in later
revisions (I hope).

No cluster differences expected.

</pre>
<p>[base/gdevm1.c]</p>
</blockquote>

<p><strong><a name="2011-02-21T171210.825257Z"></a>
2011-02-21T17:12:10.825257Z Robin Watts</strong></p>
<blockquote>
<pre>
Recommit of 12163 to the trunk.

The fit_copy macro checks for the start address being off the top of the
screen, and clips it to zero. When it does this, it does: data -= y * raster,
which gives problems if raster is a uint ( as uint * int == uint in C) and
data is a 64 bit pointer.

The fix is simply to cast the result to an int before using it. This solves
various SEGVs with the mono_copy_mono using mono_copy_rop code.

No cluster differences expected.

</pre>
<p>[base/gxdevice.h]</p>
</blockquote>

<p><strong><a name="2011-02-21T160425.039434Z"></a>
2011-02-21T16:04:25.039434Z Chris Liddell</strong></p>
<blockquote>
<pre>
The structure containing the pthreads native elements making up a
gp_semaphore structure was ending up incorrectly aligned on
sparc32 Linux systems, and caused a bus error. Annoyingly, sparc32
uses 32 bit pointers but requires 64 bit aligment.

This change enforces maximum alignment for the elements of
gp_semaphore, for the current platform.

No cluster differences expected.

Bug 691989

</pre>
<p>[base/lib.mak base/gpsync.h]</p>
</blockquote>

<p><strong><a name="2011-02-21T122920.951013Z"></a>
2011-02-21T12:29:20.951013Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix stupid typo in gsroprun.c that was causing templated rops to be different
to non templated rops. With this fixed the cluster shows identical results
(modulo indeterminisms), but the templated code is faster - so enable by
default.

No cluster differences expected.

</pre>
<p>[base/gsroprun.c]</p>
</blockquote>

<p><strong><a name="2011-02-20T124120.382249Z"></a>
2011-02-20T12:41:20.382249Z Robin Watts</strong></p>
<blockquote>
<pre>
Initial reorganisation of code towards using copy_rops for copy_mono.

Split the guts of mem_mono_strip_copy_rop out into a separate function
mem_mem_strip_copy_rop_dev. This new function handles the actual copy in
device space, leaving the original to cope with fiddling the rop according
to colors.

This 'inner' function is moved to gdevm1.c so it is present in both gs
and ghostpcl builds. The existing (bitrotted) code in gdevm1.c to
'USE_COPY_ROP' is revamped to call mem_strip_copy_rop_dev, but is disabled
currently as the cluster is showing a few differences that need to be
tracked down.

Also, this introduces new code to do gsroprun's using code in a generic
header file that gets repeatedly #included with different options. This
code is currently disabled until we can verify that it gives identical
results. The new 'templated' code uses native ints where possible, and
(in initial limited testing) seems to perform better than copy_mono.

No cluster differences expected.

</pre>
<p>[base/gdevmem.h base/lib.mak base/gsroprun.c base/gdevm1.c base/gsropt.h base/gsroprun1.h base/gdevmr1.c]</p>
</blockquote>

<p><strong><a name="2011-02-19T070113.923016Z"></a>
2011-02-19T07:01:13.923016Z Alex Cherepanov</strong></p>
<blockquote>
<pre>
Add a missing check for null value during PDF resource enumeration.
Bug 691892, customer 532.
</pre>
<p>[Resource/Init/pdf_main.ps]</p>
</blockquote>

<p><strong><a name="2011-02-18T132259.764503Z"></a>
2011-02-18T13:22:59.764503Z Robin Watts</strong></p>
<blockquote>
<pre>
Committing fix for Bug 689031 submitted by Shailesh Mistry under the
bug bounty program. Tests out fine (1 minor difference, looks like a
progression to me).

See bug for full discussion, but basically this removes a few calls to
path_position_valid in exchange for accessing the equivalent data kept
locally.


</pre>
<p>[base/gxchar.c base/gzpath.h base/gxccache.c base/gspath1.c]</p>
</blockquote>

<p><strong><a name="2011-02-18T115125.345393Z"></a>
2011-02-18T11:51:25.345393Z Ken Sharp</strong></p>
<blockquote>
<pre>
Enhancement (pdfwrite) : performance improvement

Bug #691946 &quot;Conversion to PDF becomes slower and slower&quot;

There are many places where pdfwrite compares composite objects for equality. This can
be a very slow process, depending on the nature of the object, and becomes progressively
slower as more object are added to storage.

Previously we had added a MD5 hash to the stream data of a cos_stream in order to
improve the performance when checking fonts for equality, this change takes the whole
process much further. We now store an MD5 'fingerprint' for each composite object, 
initially this is not computed and is marked as not valid.

Whenever an equality test takes place we check to see if the composite object has an MD5
hash calculated, and if it does, we compare the MD5 hashes. If it does not then we 
compute an MD5 hash, store it, and mark it as valid. Note that for cos_stream types
we store *two* hashes, one for the dictionary and one for the stream data.

If we alter the contents of a composite object then we mark its MD5 hash as invalid so
that we recompute it on the next occurence. Technically there could be a problem if
a composite object contains a composite object, and the descendant object is altered
after the MD5 hash is calculated for the parent. However this should not occur given
the way these structures are used (these are pdfwrite internal structures, *not* PS or
PDF objects available to the interpreter).

This very significantly improves performance on some files, the test file for bug
#691946 takes 2642 seconds without this change (and DetectDuplicateImages true) while
it takes 963 seconds after this change.

Note that this change depends on revision 12169 and should ideally be used with
revisions 12168 to 12171 inclusive.

No other differences expected.
</pre>
<p>[base/gdevpdfo.c base/gdevpdfo.h]</p>
</blockquote>

<p><strong><a name="2011-02-18T113756.561896Z"></a>
2011-02-18T11:37:56.561896Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : images being scaled incorrectly

Found while dealing with other problems. pdfwrite uses the image 'height' (rendered
height) and number of lines of data to calculate a 'scale' which it then applies to
the current Transformation Matrix in order to calculate an image matrix.

However, when an image was detected as a duplicate, the scale factor was calculated
from the first image's dimensions, and then applied to the CTM for the second matrix.

This did not appear to cause problems for PostScript and PDF but causes serious bugs
in a number of PCL files, and was clearly incorrect. We now save and restore the
height and width when substituting images to prevent this problem

</pre>
<p>[base/gdevpdfj.c]</p>
</blockquote>

<p><strong><a name="2011-02-18T113207.033929Z"></a>
2011-02-18T11:32:07.033929Z Ken Sharp</strong></p>
<blockquote>
<pre>
enhancement (pdfwrite) : Allow duplication image detection to be disabled

pdfwrite tests every (non-inline) image against every other stored image to see if it is
a duplicate, and if so does not embed the duplicate in the output but simply references
the original.

This can be slow for files with many images (each stored image must be checked when a
new image is encountered) and may be of limited benefit.

The new flag DetectDuplicateImages (default true) can be used to enable or disable
this behaviour

No differences expected
</pre>
<p>[base/gdevpdfj.c base/gdevpdfx.h base/gdevpdfp.c doc/Ps2pdf.htm base/gdevpdfb.h]</p>
</blockquote>

<p><strong><a name="2011-02-18T112524.853829Z"></a>
2011-02-18T11:25:24.853829Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix (pdfwrite) : Correction to an equality test

This fixes a long-standing bug when checking the equality of patterns. 

We need to ensure when substituting patterns that neither of the patterns is already
substituted. But the code only tested one of the patterns (and was a duplicate of
another test), which led to incorrect results. This should always have been a problem
but for some reason seems to have been masked in previous releases. New code for
testing equality of composite objects revealed the problem.

No differences expected, as the problem is only revealed with code which follows in a
subsequent commit.
</pre>
<p>[base/gdevpdfi.c]</p>
</blockquote>

<p><strong><a name="2011-02-18T111523.457563Z"></a>
2011-02-18T11:15:23.457563Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix a typo in an enumerated type. No differences expected.
</pre>
<p>[base/gxhldevc.h base/gxhldevc.c base/gdevpdfg.c]</p>
</blockquote>

<p><strong><a name="2011-02-15T163659.934186Z"></a>
2011-02-15T16:36:59.934186Z Henry Stiles</strong></p>
<blockquote>
<pre>
Double the allowed space for cached chars and increase the maximum
byte size of a single glyph that can be cached.
</pre>
<p>[base/gsfont.c]</p>
</blockquote>

<p><strong><a name="2011-02-15T150755.282721Z"></a>
2011-02-15T15:07:55.282721Z Ray Johnston</strong></p>
<blockquote>
<pre>
Fix for building the gs***w64.exe self extracting installer compatible with
the new 64-bit binary naming and makefile macro (BUILD_SYSTEM)
</pre>
<p>[psi/winint.mak]</p>
</blockquote>

<p><strong><a name="2011-02-15T092128.927211Z"></a>
2011-02-15T09:21:28.927211Z Chris Liddell</strong></p>
<blockquote>
<pre>
Ensure that the OpenPrinting drivers get removed from the drivers list
if iconv/libiconv are not available.

The strings used to identify the drivers in the list were incorrect.

</pre>
<p>[base/configure.ac]</p>
</blockquote>

<p><strong><a name="2011-02-14T203933.924424Z"></a>
2011-02-14T20:39:33.924424Z Robin Watts</strong></p>
<blockquote>
<pre>
Fix Bug 691917. In revision 11146 I made op_array_table_global and
op_array_table_local be elements of the context rather than being
globals, and changed all the code to access these elements through
the context.

Unfortunately I forgot to cope with when new contexts are generated by
forking execution. The correct fix is, I believe to simply copy the
op_table pointers over to the new context. This has been done here, and
seems to solve the reported bug.

No cluster differences expected.

</pre>
<p>[psi/zcontext.c]</p>
</blockquote>

<p><strong><a name="2011-02-14T110439.509187Z"></a>
2011-02-14T11:04:39.509187Z Till Kamppeter</strong></p>
<blockquote>
<pre>
Removed a tab accidentally introduced in rev 12082.
</pre>
<p>[Resource/Init/cidfmap]</p>
</blockquote>

<p><strong><a name="2011-02-10T171423.128533Z"></a>
2011-02-10T17:14:23.128533Z Chris Liddell</strong></p>
<blockquote>
<pre>
Ensure that a --build option is propogated to the other
configure scripts we call.

</pre>
<p>[base/configure.ac]</p>
</blockquote>

<p><strong><a name="2011-02-10T132158.493309Z"></a>
2011-02-10T13:21:58.493309Z Ken Sharp</strong></p>
<blockquote>
<pre>
fix error in revision 12140

When fetching the size of the stream for a /Indexed colour space, omitted to check if the
/Length of the stream was an indirect object. Now dereference the object if this is the
case.

Should fix the 14 files with errors introduced in 12140.
</pre>
<p>[Resource/Init/pdf_draw.ps]</p>
</blockquote>

<p><strong><a name="2011-02-10T104326.255155Z"></a>
2011-02-10T10:43:26.255155Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix : colour space handling bug and improved handling of broken ICC space

Bug #691941 &quot;Interpretation of PDF aborts with /typecheck&quot;

The PDF file in the specimen contains an invalid colour space of the form:

/Indexed [/ICCBased &lt;&lt;/N 1 /Alternate [/Indexed /DeviceRGB 255 7 0 R]&gt;&gt;] 255 7 0 R]

The number of components in the ICCBased specification is incorrect, as the profile has
3 channels. This was not detected previously. Falling back to the /Alternate we see
that we have a /Indexed space depending on a /Indexed space which is also invalid, but
we choose to ignore this.

There was also a bug in the colour space handling for ICCbased spaces which caused a
typecheck if the alternate space was a /Indexed space.

Finally, the PDF interpreter is updated so that when given a stream as the data source
for a /Indexed space it reads and returns a string which is the greater of the declared
size of the stream, or the calculated size required, given the number of components. 
Previously we always returned the calculated size, which was too little in this case
as the number of components in the ICCBased space is incorrect.

With these changes the (invalid) specimen file runs to completion. 

No differences expected.
</pre>
<p>[psi/zcolor.c psi/zicc.c Resource/Init/pdf_draw.ps]</p>
</blockquote>

<p><strong><a name="2011-02-10T103323.506445Z"></a>
2011-02-10T10:33:23.506445Z Ken Sharp</strong></p>
<blockquote>
<pre>
Fix Bug #691918

Update the Unicode decodings applied to TrueType fonts to match the latest Adobe glyph
list. Fixes some problems with incorrect mappings and adds numerous new mappings. A
similar but less extensive change is made to the FCO_Unicode mappings as well.

Thanks to SaGS for the work on this problem.

No differences expected as these are only used for ToUnicode CMaps.</pre>
<p>[Resource/Decoding/Unicode Resource/Decoding/FCO_Unicode]</p>
</blockquote>
</body>
</html>