/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 ("opvp")
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 "show machinery".
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 "$(DD)"
and ".dev" runes added to them.
Also, rearrange the "pre-declared" 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 "Differences in colour with ps2write"
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 "Differences in dithered output with ps2write"
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 <= 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 & 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 "reset" 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 "transient" 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 "cups" 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 "CLUSTER_UNTESTED" 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 "cups" 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 -> 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 "new customer feb 2011", 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 "Conversion to PDF becomes slower and slower"
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 "Interpretation of PDF aborts with /typecheck"
The PDF file in the specimen contains an invalid colour space of the form:
/Indexed [/ICCBased <</N 1 /Alternate [/Indexed /DeviceRGB 255 7 0 R]>>] 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>
|