| # | User | Message | Date |
| 1742 | Henrik | I don't know. I don't have the HP1200 anymore. :-) | 25-Jun 7:53 |
| 1741 | Graham | so does using %//prn work any better than using echo?? | 24-Jun 20:43 |
| 1740 | Henrik | another advantage is that it's fairly simple to add a new method. it took 20 minutes to add Ghostscript printing via the win32pr driver and when it was added, I could print anything, which is a nice thing about this abstraction. | 24-Jun 14:49 |
| 1739 | Henrik | I can release the code for you, if you're interested. | 24-Jun 14:47 |
| 1738 | Henrik | it is largely oriented towards use on Win98/XP. | 24-Jun 14:46 |
| 1737 | Henrik | the downside with this system is that I'm still not using straight native windows printing. the good side is that it offers many alternative solutions for printing. | 24-Jun 14:46 |
| 1736 | Henrik | the first part can probably be replaced with your own stuff | 24-Jun 14:45 |
| 1735 | Henrik | you feed a postscript layout through a parser, which fills in dynamic values and then it's run through postscript.r and then it's fed through system-print to the appropriate printing method. | 24-Jun 14:45 |
| 1734 | Henrik | There is also a print queue system, which you can opt to use, if you don't want to print directly. http://rebol.hmkdesign.dk/files/system-print-queue.png | 24-Jun 14:43 |
| 1733 | Henrik | It supports currently print to file, print to LPT, print to Ghostscript, print to screen (as in screenshot), print to ethernet printer and to a custom network printer server made in REBOL for some simple printer sharing. | 24-Jun 14:42 |
| 1732 | Henrik | http://rebol.hmkdesign.dk/files/system-print.png | 24-Jun 14:39 |
| 1731 | Henrik | Geomol, I built a printer abstraction system called system-print for my apps. It's not finished, but for what it does it works sort of OK. You can choose printing method via a GUI and it auto-detects Ghostscript and uses it if necessary. | 24-Jun 14:37 |
| 1730 | Geomol | "There are many printer specific bugs that require a windows printer driver to make postscript printing work properly" Bad news for me! I'm working on a new version of a huge application for a customer, and I was about to rebuild their printing in a couple of months. I planned to use the rebol postscript dialect. | 24-Jun 14:29 |
| 1729 | Graham | ghostscript can generate pcl from postscript ... and then you can feed it to the driver | 24-Jun 12:21 |
| 1728 | Henrik | if anything, perhaps that process is faster | 24-Jun 12:20 |
| 1727 | Graham | as opposed to sending PCL to the printer... well, that is my guess | 24-Jun 12:20 |
| 1726 | Graham | the HP driver probably takes PCL and creates a bitmap and then sends it to the printer | 24-Jun 12:20 |
| 1725 | Henrik | it might not | 24-Jun 12:18 |
| 1724 | Graham | My guess is that it doesn't have any PCL engine on boad. | 24-Jun 12:18 |
| 1723 | Graham | take the printer output and send it directly to the printer if you can .. see what happens | 24-Jun 12:18 |
| 1722 | Graham | setup a HP printer ( eg an old laserjet ) and set the driver to print to a file | 24-Jun 12:17 |
| 1721 | Henrik | and a new PC. that stupid machine just died. glorious day today. | 24-Jun 12:17 |
| 1720 | Henrik | hmm... need some examples for that. | 24-Jun 12:17 |
| 1719 | Graham | with a PCL driver | 24-Jun 12:17 |
| 1718 | Graham | If it doesn't understand it .. then it's just a dumb printer | 24-Jun 12:16 |
| 1717 | Graham | try sending some raw PCL to the printer to see what happens | 24-Jun 12:16 |
| 1716 | Henrik | well, as long as this one is.. :-) | 24-Jun 12:15 |
| 1715 | Graham | no | 24-Jun 12:15 |
| 1714 | Henrik | yes it is. I think all HP printers are. | 24-Jun 12:14 |
| 1713 | Graham | the product description says that the HHP 1505 is a host based PCL printer | 24-Jun 12:14 |
| 1712 | Henrik | if it can that makes my task simpler. | 24-Jun 12:14 |
| 1711 | Henrik | I did not know that. | 24-Jun 12:13 |
| 1710 | Graham | Since the printer driver is host based, it would be doing the same thing as well. | 24-Jun 12:05 |
| 1709 | Graham | and then you can dump the resulting prn file to the printer vs creating a bitmap?? | 24-Jun 12:03 |
| 1708 | Graham | You do know that ghostscript can convert ps to pcl ?? | 24-Jun 12:03 |
| 1707 | Graham | do you need to print as soon as possible? | 24-Jun 12:00 |
| 1706 | Henrik | yes, I don't expect it to be as fast as PS, but this is like... 25-50 times slower. :-) | 24-Jun 11:56 |
| 1705 | Graham | so it will always be slower than a PS printe. | 24-Jun 11:55 |
| 1704 | Henrik | now if they stopped that winprinter crap and had postscript as standard in all printers... the hardware to do that should be fairly cheap for that today. | 24-Jun 11:55 |
| 1703 | Graham | cheap host based printer | 24-Jun 11:55 |
| 1702 | Henrik | yeah :-( | 24-Jun 11:54 |
| 1701 | Henrik | it seems gsprint provides many more options... I will have to investigate that. | 24-Jun 11:54 |
| 1700 | Graham | you need to create a PCL driver :) | 24-Jun 11:54 |
| 1699 | Henrik | mine and budget. we can't afford a better printer. | 24-Jun 11:53 |
| 1698 | Graham | who's decision was it to purchase that? | 24-Jun 11:53 |
| 1697 | Henrik | well, the bitmap it sends is over 2 MB in size. that's pretty huge for a pure b/w bitmap I think. | 24-Jun 11:53 |
| 1696 | Henrik | HP Laserjet 1505. | 24-Jun 11:52 |
| 1695 | Graham | what printer do you have now? | 24-Jun 11:52 |
| 1694 | Graham | faster PC | 24-Jun 11:52 |
| 1693 | Henrik | the only problem is the speed. I really wish I could speed it up. | 24-Jun 11:51 |
| 1692 | Henrik | now with a new printer, I have to create a completely different setup with ghostscript. | 24-Jun 11:51 |
| 1691 | Graham | well, then there is very little option except to use ghostscript | 24-Jun 11:51 |
| 1690 | Henrik | I ranted about it, because I could not print directly to it, but had to use the adobe driver for that. | 24-Jun 11:50 |
| 1689 | Henrik | sorry if I confused you. no the HP1200 one is no longer being used | 24-Jun 11:50 |
| 1688 | Graham | the HP 1200 ? | 24-Jun 11:49 |
| 1687 | Graham | Huh?? | 24-Jun 11:49 |
| 1686 | Henrik | the problem is that the new printer is not a postscript printer. | 24-Jun 11:49 |
| 1685 | Graham | well, if the way you're doing it now is not working ... I suggest you try my ways :) | 24-Jun 11:48 |
| 1684 | Henrik | it's a confusing subject, because there are 20 different ways to print :-) | 24-Jun 11:48 |
| 1683 | Graham | so might fix your problems as well. | 24-Jun 11:46 |
| 1682 | Graham | Maybe this is even going thru the windows printer driver | 24-Jun 11:46 |
| 1681 | Graham | and so %//prn will still work ... | 24-Jun 11:43 |
| 1680 | Graham | this is what I had to do for usb printers .. http://synapsedirect.com/forums/thread/396.aspx | 24-Jun 11:41 |
| 1679 | Henrik | I've been informed that we are not using win98 anymore (yay!) | 24-Jun 11:40 |
| 1678 | Graham | it might not work under Windows 98 | 24-Jun 11:38 |
| 1677 | Henrik | so %prn is a DOS/win32 thing that REBOL just uses? | 24-Jun 11:36 |
| 1676 | Graham | from Andrew Martin Printer: func [Text [string!] /Page] [ secure [ %//prn [allow write] ] write %//prn Text ; Append Carriage Return (CR) and Page Feed. if Page [write/binary %//prn "^(0D)^(page)"] Text ] | 24-Jun 11:34 |
| 1675 | Graham | %//lpt1 is also possible, but according to google, %//prn diverts to the first availabel printer | 24-Jun 11:33 |
| 1674 | Henrik | interesting... but ok, now my focus is to make it work on any printer. as mentioned it is fed through ghostscript. when I read about GSPrint it almost seems like it does the same thing. it even uses the same driver. | 24-Jun 11:31 |
| 1673 | Graham | But never had a problem | 24-Jun 11:30 |
| 1672 | Graham | dunno | 24-Jun 11:30 |
| 1671 | Henrik | interesting... what decides that %//prn is LPT1? | 24-Jun 11:30 |
| 1670 | Graham | when printing to lpt1 | 24-Jun 11:29 |
| 1669 | Graham | this is what I do ... write %//prn content | 24-Jun 11:29 |
| 1668 | Henrik | I just echo'ed it through DOS to LPT1:. | 24-Jun 11:28 |
| 1667 | Graham | what was your code to send the ps to the printer?? | 24-Jun 11:27 |
| 1666 | Henrik | and I tried both with similar results | 24-Jun 11:27 |
| 1665 | Henrik | it can use both. | 24-Jun 11:27 |
| 1664 | Graham | parallel or usb? | 24-Jun 11:27 |
| 1663 | Henrik | HP Laserjet 1200 | 24-Jun 11:26 |
| 1662 | Graham | and which were you using? | 24-Jun 11:26 |
| 1661 | Henrik | It uses parallel/usb | 24-Jun 11:26 |
| 1660 | Graham | what sort of printer is it?? | 24-Jun 11:25 |
| 1659 | Graham | I got some notes somewhere that async printing to a postscript printer caused me problems. | 24-Jun 11:25 |
| 1658 | Henrik | doesn't that only work for ethernet printers? | 24-Jun 11:25 |
| 1657 | Graham | so, you just writing to port 9100 ? | 24-Jun 11:20 |
| 1656 | Henrik | nope | 24-Jun 11:19 |
| 1655 | Graham | Is it a shared printer? | 24-Jun 11:19 |
| 1654 | Henrik | I don't think it's the postscript itself that's buggy, but the transmission of the code to the printer. Perhaps they are screwing around with port settings inside the driver which we don't know about. So it may be a lower level problem. | 24-Jun 11:19 |
| 1653 | Henrik | I don't use GSView at all. | 24-Jun 11:18 |
| 1652 | Graham | but I guess gswin32 should complain if there is an error in the ps code | 24-Jun 11:18 |
| 1651 | Graham | the point of using gsview is as a debugging tool | 24-Jun 11:17 |
| 1650 | Henrik | will have a look at gsprint... | 24-Jun 11:17 |
| 1649 | Henrik | I call gswin32c.exe and feed it parameters to use the win32pr driver, which sends a bitmap to the printer given as a parameter in the same call. | 24-Jun 11:16 |
| 1648 | Graham | so, you're also using gsprint? | 24-Jun 11:13 |
| 1647 | Henrik | No, ghostscript generates a bitmap for printing on any printer, which is what I have to use now. I used the adobe driver for the HP 1200. | 24-Jun 11:11 |
| 1646 | Graham | so, you send postscript to ghostscript when then generates postscript again to send to the HP printers? | 24-Jun 11:10 |
| 1645 | Henrik | I don't use GSView, I use the printer with Ghostscript as passthrough. | 24-Jun 11:09 |
| 1644 | Graham | or is interpreted interactively by ghostscript? | 24-Jun 11:05 |
| 1643 | Graham | what happens when the code you send is rendered by gsview? | 24-Jun 11:04 |
| 1642 | Henrik | I have worked for many weeks on the problem and it's unsolvable, so I went to Ghostscript instead, but I'm unhappy with its speed. | 24-Jun 10:59 |
| 1641 | Graham | and you're sure that your postscript code is correct?? | 24-Jun 10:40 |
| 1640 | Henrik | I've also seen a Laserjet 4500 lock completely up, when you feed it a specific postscript or PDF file. | 24-Jun 9:54 |
| 1639 | Henrik | I read about the HP Laserjet 1200 and it has such a bug in its postscript implementation that is easiest worked around in the driver. | 24-Jun 9:54 |
| 1638 | Henrik | I had problems with feeding postscript files generated by postscript.r directly to an HP Laserjet 1200. It would stop printing after the first job. Feeding it through Ghostscript or the adobe postscript printer driver solved the problem, but now the printer is replaced with a different one with different issues. | 24-Jun 9:51 |
| 1637 | Graham | what do you mean by printer specific bugs? | 24-Jun 9:35 |
| 1636 | Henrik | I gave in, and have begun using ghostscript for printing postscript. There are many printer specific bugs that require a windows printer driver to make postscript printing work properly, so I now use the mswinpr2 driver. However it eats about 40 MB RAM printing one page. Anyone got ideas on how to reduce that? | 24-Jun 8:52 |
| 1635 | Henrik | And when I say the letter is tall in Helvetica or Times, that means it may not be so in other fonts. I don't believe a font like Verdana does this. This is why when getting the absolute center for a font, you must calculate it using all glyphs in the font. | 20-Apr 14:19 |
| 1634 | Henrik | it depends on the chars you use. if you use a word like "judge", the word might appear offset downward, because there are no really tall letters in that word. if you use a word like "Greg", the word might appear more centered. If you say "GGG", the word might appear offset upward, because "G" is a tall character in Helvetica or Times. But overall, if you write a long sentence like that, the words should appear centered. | 20-Apr 14:16 |
| 1633 | Geomol | I can see, that text in tables in html is centered more like you want it, at least in Safari. Actually the text is much lower in Safari, so there is more space above the text than below, if you use words with 'g'. I can't judge, if they do a simple calculation or use the font box. | 20-Apr 14:12 |
| 1632 | Henrik | but I do wish that each char in a font had a center point that indicates the absolute center of a character both horizontally and vertically. horizontally, that would be individual for each char, but vertically it has to be identical for all chars, like the baseline is. | 20-Apr 13:57 |
| 1631 | Henrik | adobe didn't invent the baseline | 20-Apr 13:54 |
| 1630 | Henrik | the baseline is a typographical tool. it is the place where your letters are "resting" against, just like when you were learning to write in school, you had a guide line to write characters on. but the baseline itself is completely useless for vertical centering of text. | 20-Apr 13:54 |
| 1629 | Geomol | That is the reason, that they put the baseline as they did? | 20-Apr 13:52 |
| 1628 | Henrik | and the position calculation is around the baseline. | 20-Apr 13:52 |
| 1627 | Henrik | it is not centered, because the baseline is not at the center of the text. if only it were :-) | 20-Apr 13:51 |
| 1626 | Geomol | Don't you think, it already is centered, if you take underline into consideration? It seems weird to me, that Adobe would position text being off some amount, either up or down. | 20-Apr 13:51 |
| 1625 | Henrik | because we are already doing it correctly using stringwidth, namely by calculating the text size accurately inside postscript. the same should count for the vertical size. it's strange that information is so hard to get. | 20-Apr 13:49 |
| 1624 | Geomol | ok | 20-Apr 13:48 |
| 1623 | Henrik | for the syntax and input yes, but if you need accuracy, you need to get the information via postscript. | 20-Apr 13:47 |
| 1622 | Geomol | Sorry, that I find it hard to understand, what you mean from time to time, my fault. I get you now. I would put things like margins, linespace, vertical position within tables, etc. in a dialect above the postscript dialect level. Doing it that way, the same postscript dialect can be used for all sorts of layout engines, because it has little restriction. | 20-Apr 13:45 |
| 1621 | Henrik | well, possibly. I'll see if that works for now. | 20-Apr 13:41 |
| 1620 | Geomol | Then adjust the 10 factor, until you're satisfied. And that should then work for all fontsizes. | 20-Apr 13:40 |
| 1619 | Geomol | If you have different fontsizes in your tables, you could do something like: y-pos: y-pos - (fontsize / 10) | 20-Apr 13:39 |
| 1618 | Henrik | then I have to do that for each single individual case. with the deadline I have to produce this table, that may be my option for now, but that is definitely not optimal. | 20-Apr 13:37 |
| 1617 | Geomol | :) In REBOL/View, there is things like offsets to position text within field and so. Couldn't you go with something like that? Just subtract a little from each vertical position to get the text a little down, if you want? | 20-Apr 13:36 |
| 1616 | Henrik | yes! now you get it | 20-Apr 13:34 |
| 1615 | Geomol | But you're right, that if you really want that, then you need to get info from each letter in the font. | 20-Apr 13:34 |
| 1614 | Henrik | sigh... I've already said 4 times that I use the alphabet to prevent this! :-) | 20-Apr 13:34 |
| 1613 | Geomol | Because if you want that, then it'll look strange, because each line in the table will have text jumping up and down, depending on whether you have letters like 'g' and 't' or you just have letters like 'a'. And that will look less nice to me. | 20-Apr 13:33 |
| 1612 | Henrik | ... yes :-) | 20-Apr 13:32 |
| 1611 | Geomol | Eh, the baseline is centered in each cell, right? And you're asking each word to be centered within its cell with equal space above and below the text? | 20-Apr 13:32 |
| 1610 | Henrik | That is _not_ vertically centered text. That is text that is vertically centered around the baseline. | 20-Apr 13:30 |
| 1609 | Henrik | Your method produces this: http://hmkdesign.dk/rebol/postscript/testsheet.ps | 20-Apr 13:30 |
| 1608 | Geomol | LOL :) | 20-Apr 13:29 |
| 1607 | Henrik | I. Need. Vertically. Centered. Text. :-) Is that so hard to understand? :-) | 20-Apr 13:29 |
| 1606 | Geomol | Do you have the psrefman.pdf document for PS second edition? Seciton 5.4 has a drawing of font positioning. | 20-Apr 13:29 |
| 1605 | Geomol | Ok, if it does, what you need. :-) | 20-Apr 13:28 |
| 1604 | Henrik | not top-aligned text, but text where the baseline is the center. | 20-Apr 13:27 |
| 1603 | Henrik | sorry | 20-Apr 13:26 |
| 1602 | Henrik | now I'm reallly confused. it would mean the height of the paper is somehow misleading. I tried your method in the table cells and get top-aligned text as I expected. | 20-Apr 13:26 |
| 1601 | Geomol | In my example, the baseline of all the text is vertical centered on the page. | 20-Apr 13:26 |
| 1600 | Geomol | PageSize A4 page [ font [Times 18] at 60x421 "abcdefg" font [Times 36] at 130x421 "abcdefg" font [Times 96] at 260x421 "abcdefg" ] | 20-Apr 13:24 |
| 1599 | Henrik | why doesn't that work for smaller cells? | 20-Apr 13:23 |
| 1598 | Henrik | what?... | 20-Apr 13:23 |
| 1597 | Henrik | if that's the case, let me test the theory | 20-Apr 13:21 |
| 1596 | Geomol | Then it's centered. | 20-Apr 13:21 |
| 1595 | Geomol | 0 is left side of paper. 421 is height of paper divided by 2. 842 / 2 = 421. | 20-Apr 13:20 |
| 1594 | Henrik | where did you get 0x421 from? | 20-Apr 13:20 |
| 1593 | Geomol | No, horiz and vert! | 20-Apr 13:20 |
| 1592 | Geomol | When you do things like: at 100x200 "some text" the character origin of the first character in the text is at position 100x200. | 20-Apr 13:19 |
| 1591 | Henrik | "center the text" ... are you talking about _horizontally_ centered text? | 20-Apr 13:19 |
| 1590 | Geomol | No, I didn't! :) | 20-Apr 13:19 |
| 1589 | Henrik | no, because you probably were eyeballing it. | 20-Apr 13:19 |
| 1588 | Geomol | Why would I need the font height? I didn't need that in my example to center the text. | 20-Apr 13:18 |
| 1587 | Henrik | and as mentioned at first, I already tried the font size... doesn't work. | 20-Apr 13:18 |
| 1586 | Henrik | ok, tell me then the algorithm for calculating the font height inside REBOL. :-) you cannot possibly know without reading and parsing the .PFM files yourself. | 20-Apr 13:18 |
| 1585 | Geomol | The 0x421 and 595 comes from the papersize, which is 595x842 when using A4. | 20-Apr 13:17 |
| 1584 | Geomol | There is no information about font (other than Times 40) in my example. | 20-Apr 13:16 |
| 1583 | Geomol | Remember what kind of language, PS is. | 20-Apr 13:15 |
| 1582 | Henrik | as mentioned before, that won't work, because the font information is not obtainable from inside REBOL. it has to be done inside postscript. I've already tried that method a year ago and it failed. :-) | 20-Apr 13:15 |
| 1581 | Geomol | Yes, that's what I think, you should do. Build a dialect with keywords as top, middle, bottom etc. and make that dialect know the size of the paper and correctly calculate the positions. That's the way to do it, I think. I would do it like that. | 20-Apr 13:14 |
| 1580 | Henrik | well, that's hardcoded :-) | 20-Apr 13:13 |
| 1579 | Geomol | Isn't this centered? PageSize A4 page [ font [Times 40] linewidth 0 at 0x421 "Centered text" center 595 ] | 20-Apr 13:12 |
| 1578 | Henrik | the source you are reading contains Graham's method | 20-Apr 13:08 |
| 1577 | Henrik | The bbox information for the entire font is stored in each font metric file as a [llx, lly, urx, ury] coordinate set, so I shouldn't need to calculate it. This information is crucial in order to get one line of vertically centered text. I already got everything in place except that particular number. :-) | 20-Apr 13:07 |
| 1576 | Henrik | Combining Graham's method with getting the height from the entire alphabet instead of the single word would eliminate the varying height problem you mention. But the baseline problem turns up again. | 20-Apr 13:04 |
| 1575 | Henrik | then I used Graham's method and it does practically the same thing (I forgot to test for letters like "g"), but you can successfully calculate the bbox for a text string this way, if you need it. | 20-Apr 13:03 |
| 1574 | Henrik | what I did at first was just to use the font size. that doesn't work, because it does not take the baseline into account. | 20-Apr 13:01 |
| 1573 | Henrik | accurately vertically centered text | 20-Apr 13:01 |
| 1572 | Geomol | Ok, I'm a bit lost. I'm not completely sure, what you're trying to achieve. | 20-Apr 13:00 |
| 1571 | Henrik | and this information shouldn't need to be calced if we can get that from FontBBox in the font dictionary. still hunting for how to obtain it. :-) | 20-Apr 12:59 |
| 1570 | Henrik | this way the height will be constant | 20-Apr 12:59 |
| 1569 | Henrik | that you solve by calculating the bbox for the entire alphabet instead of just the words you write | 20-Apr 12:58 |
| 1568 | Geomol | If your goal is, that the text is completely centered vertically, then you have a problem. Because how do you know, what characters to be written? If there is no 'g' in the word, you need to position it a bit lower, than if you had 'g' in the text, for it to be completely middle aligned. | 20-Apr 12:57 |
| 1567 | Henrik | The baseline problem is the one I'm hunting a solution for. About the font metrics, the bbox for the whole font is stored in FontBBox in the font dictionary. | 20-Apr 12:56 |
| 1566 | Henrik | the table is a different matter :-) it's already done, not yet as a dialect though. I will build one later. | 20-Apr 12:55 |
| 1565 | Geomol | No, text is rendered from the "character origin" (the baseline), which can be different than the center of the text. This should probably be taken care of, if needed. hm | 20-Apr 12:55 |
| 1564 | Geomol | If you wanna build a table, you calculate the position of each line like this, and send the precise coords to the postscript dialect. It would probably be best to build a new dialect on top of the postscript one, and in that dialect handle the calculations. | 20-Apr 12:53 |
| 1563 | Henrik | that assumes that the text is rendered from its own center point. it isn't, is it? | 20-Apr 12:53 |
| 1562 | Geomol | The y coord is 300 / 2 plus the 100 = 250. | 20-Apr 12:52 |
| 1561 | Geomol | A vertical positioning would be a simple calculation. Say, you want the baseline to be positioned at the middle of a 300 point high box starting at pos (100, 100). You then start by putting text at coord (100, 250). | 20-Apr 12:51 |
| 1560 | Henrik | you still need to know the size of the bbox, don't you? | 20-Apr 12:51 |
| 1559 | Geomol | So it doesn't matter, how high the font is. | 20-Apr 12:49 |
| 1558 | Geomol | In Adobe documentation, they operate with "character origin", which is the baseline, I think. If you do: 40 50 moveto (ABC) show , the origin of the A letter is at coordinate (40, 50). | 20-Apr 12:48 |
| 1557 | Henrik | so my current method is Graham's, except for calculating the entire alphabet. we should probably work on getting that information from the font metric file instead. | 20-Apr 12:45 |
| 1556 | Henrik | there is another method which is to get the bbox information from the font metric file itself. it's much faster, since it's just lookup, but I couldn't find an example of how to read it. | 20-Apr 12:44 |
| 1555 | Henrik | I got it rendered now so that the vertical position is at least consistent now, but the font is offset a few points too far down. I don't know why yet, but it's probably the baseline again. | 20-Apr 12:42 |
| 1554 | Henrik | The problem is to get the height accurately for all glyphs for a font (I just got that now). Some fonts have very high tops and very low bottoms and you want that to work for any font and letter combination we throw at it. it would be harder to get that information inside REBOL than inside postscript. | 20-Apr 12:41 |
| 1553 | Geomol | If vertical position should be in the dialect, I think, it should be based on a real postscript feature. If such a thing isn't found in postscript, it should be implemented on a higher level, shouldn't it? | 20-Apr 12:38 |
| 1552 | Henrik | so if the bounding box does that for a single word, we need to use all chars in the alphabet to calculate the height correctly for any char combination. it does not do that right now | 20-Apr 12:34 |
| 1551 | Henrik | seems it's still not accurate :-( it still calculates the baseline incorrectly when using letters like "g" | 20-Apr 12:32 |
| 1550 | Henrik | Geomol, there is some code duplication in there. Perhaps it can be optimized? | 20-Apr 12:30 |
| 1549 | Henrik | (table is my own component, not part of postscript.r :-)) | 20-Apr 12:28 |
| 1548 | Henrik | example of adjustments: http://hmkdesign.dk/rebol/postscript/testsheet.ps | 20-Apr 12:27 |
| 1547 | Henrik | moved the source to http://hmkdesign.dk/rebol/postscript/postscript.r | 20-Apr 12:26 |
| 1546 | Geomol | I'll take a look at your changes... | 20-Apr 12:26 |
| 1545 | Geomol | Yes, the y width seems to be for vertical writing, like in chinese. | 20-Apr 12:24 |
| 1544 | Henrik | allegedly the method graham describes is not very efficient, but it works accurately and that's what I want. | 20-Apr 12:24 |
| 1543 | Henrik | updated source code for download | 20-Apr 12:23 |
| 1542 | Henrik | but now I have margin working too. it was simple to add. | 20-Apr 12:21 |
| 1541 | Henrik | it has something to do with offsetting from the glyph origin, I think | 20-Apr 12:21 |
| 1540 | Henrik | I use it only for X. The Y component is not a height, but something else. | 20-Apr 12:20 |
| 1539 | Geomol | I was looking at the postscript operator STRINGWIDTH. It seems to be able to take two arguments, for x and y width. Are you using that? | 20-Apr 12:19 |
| 1538 | Henrik | now it would be nice with some form of margin management | 20-Apr 12:09 |
| 1537 | Henrik | The changes are: - Stores the font size inside PS every time a new font is selected. This is not used however, but perhaps is useful in the future. - Added bottom, middle and top alignment for TEXT. Similarly to how you specify a size for LEFT, CENTER and RIGHT, you can enter a size for TOP, MIDDLE and BOTTOM: "Some text" center 400 middle 200 Both sets are optional. The default alignment is LEFT and BOTTOM. My changes are marked HMK in the source. I hope it is of use. | 20-Apr 12:08 |
| 1536 | Henrik | Geomol, you may find my changes here: http://hmkdesign.dk/rebol/postscript.r | 20-Apr 12:05 |
| 1535 | Henrik | it also helps better top alignment | 20-Apr 11:59 |
| 1534 | Henrik | yes! got grahams method working now. thanks. | 20-Apr 11:59 |
| 1533 | Henrik | yes | 20-Apr 0:28 |
| 1532 | Graham | aren't you both in the same timezone? | 20-Apr 0:23 |
| 1531 | Henrik | time for bed... Geomol can take over in the morning. :-) | 20-Apr 0:22 |
| 1530 | Henrik | Got the font size to work, but it doesn't take the baseline into account. | 20-Apr 0:21 |
| 1529 | Henrik | I get a postscript error. | 20-Apr 0:21 |
| 1528 | Graham | what do you mean it doesn't work? | 20-Apr 0:19 |
| 1527 | Henrik | nope, that doesn't work either | 20-Apr 0:14 |
| 1526 | Graham | faq: http://www.postscript.org/FAQs/language/node67.html | 20-Apr 0:11 |
| 1525 | Henrik | though not in that form | 20-Apr 0:11 |
| 1524 | Henrik | tried that one, couldn't get it to work. | 20-Apr 0:10 |
| 1523 | Henrik | how do I call it again, with /fontsize or fontsize? | 20-Apr 0:10 |
| 1522 | Graham | The ``charpath'' operator extracts the graphic shapes of its string operand and appends them to the current path in the graphic state. These shapes can then be processed by other PostScript operators. To get the actual size of the area touched by a character a simple approach is gsave newpath 0 0 moveto (X) false charpath flattenpath pathbbox grestore This code places four numbers on the stack, representing the coordinates of the lower left and upper right corners of the bounding box enclosing the character ``X'' rendered with the current point at (0,0). Leaving the flattenpath out will cause it to be less accurate, but it will take up less memory and be faster. | 20-Apr 0:09 |
| 1521 | Graham | it's the offset from the baseline | 20-Apr 0:09 |
| 1520 | Henrik | stringwidth returns the width and some form of Y value that is not the height, but something else. | 20-Apr 0:08 |
| 1519 | Graham | I seem to remember justification routines get the word size, drop the height value and just work on the width | 20-Apr 0:07 |
| 1518 | Graham | /fontsize (size) def | 20-Apr 0:05 |
| 1517 | Graham | not sure about that .. but you can set a postscript variable to hold the latest fontsize and reference that | 20-Apr 0:04 |
| 1516 | Henrik | the width of the text yes, not the height. and I may not know the font at rendering time as that may be set in a completely different part of the program. | 20-Apr 0:03 |
| 1515 | Graham | and there are postscript commands for getting the size of the text | 20-Apr 0:01 |
| 1514 | Graham | you define the font height when you set the font. | 20-Apr 0:01 |
| 1513 | Henrik | Geomol, I have the structure change needed for text to support the font height, so the vertical centering can be made, but I just can't find the postscript commands necessary to obtain the font height. | 20-Apr 0:00 |
| 1512 | Graham | huh? | 20-Apr 0:00 |
| 1511 | Henrik | looks like getting something so simple as the font height is rather difficult in postscript | 20-Apr 0:00 |
| 1510 | Reichart | I'm working on displaying Qwikis (Wikis) on Cell phones. It is a connected problem, viewing something intended for one medium on another. My basic plan is: - Images - make a thumbnail, then let them click on it to see a larger or a list of sizes of their choice - Tables - Show the name of the table, and then a bias, column or row, and offer a search. Then drill down. When printing big tables to paper you have to decide what to do if the table is simply too big for a single piece of paper. Put the table at the end on multiple pages? Put a small version of the table (perhaps unreadable), and say "See table on Exhibit X"? Put the table on multiple pages inline? Convert the table to something else, for example more like a query result, where each row is a chunk of data in a new format? | 19-Apr 17:08 |
| 1509 | Henrik | need it for table cells | 19-Apr 17:04 |
| 1508 | Henrik | I think I have a crude way to do it for one line. | 19-Apr 17:03 |
| 1507 | Reichart | That is the big problem, basically, that as in going across pages (or being wide). | 19-Apr 16:49 |
| 1506 | Geomol | No, I don't think, I've looked at that yet. I might tomorrow. | 19-Apr 16:35 |
| 1505 | Henrik | Geomol. have you been looking at vertically centered text? It could be added as a y parameter to 'text, where we already use an x parameter for the string box size. | 19-Apr 15:18 |
| 1504 | Henrik | "dialect" | 19-Apr 10:39 |
| 1503 | Henrik | anyone been working on a postscript table generator for the dialet? | 19-Apr 10:39 |
| 1502 | Geomol | I needed the decimal! for text size in alignment, because postscript work with 72 dot pr. inch by default. Putting text on the page often need the text to be with sub-unit precision. It was possible to put the text with sub-unit before, but now also alignment can be with sub-unit precision. | 26-Feb 17:06 |
| 1501 | Henrik | cool :-) | 26-Feb 16:24 |
| 1500 | Geomol | Yes, but it only worked with integer! text-size. I've added decimal! option, and this seems to work too. (sub-unit precision) I have a new version ready soon. | 26-Feb 16:24 |
| 1499 | Henrik | it has worked fine in the past, I believe | 26-Feb 16:22 |
| 1498 | Geomol | Do you use right-aligned text? | 26-Feb 16:03 |
| 1497 | Henrik | I've only tried transformations for single paths, sorry. | 26-Feb 15:54 |
| 1496 | Geomol | Has anyone tried the transformations? There might be an unwanted restriction in the implementation. I can't get transformations to work for a whole page, only for one path at a time. | 26-Feb 15:05 |
| 1495 | Geomol | Updated the documentation: http://home.tiscali.dk/john.niclasen/postscript/postscript.html Added describtion of comment. | 26-Feb 15:03 |
| 1494 | Henrik | I'll give it a shot when I get access to the testing equipment. | 24-Feb 19:24 |
| 1493 | Geomol | Output from TextEdit printed to a PS file has this in the end: %%Trailer %%Pages: 1 %%EOF ^D The last char (ctrl-D) is hex 04. I think, the comment lines are according to "PostScript Language Document Structuring Conventions Specification". You can find this document on the net at Adobe. So there is a difference in how %%Pages comments are handled. And postscript.r doesn't put hex 04 in the end. You could try some of these changes, when you have the problem. | 24-Feb 18:23 |
| 1492 | Henrik | a simple check: does a PS example from the internet end the same way as a postscript.r generated file? | 24-Feb 17:56 |
| 1491 | Henrik | no, sorry, under Linux I also print to the device directly. LPR was when I used PDF for printing rather than PS. | 24-Feb 17:44 |
| 1490 | Henrik | I've seen the bug in two separate HP laser printers | 24-Feb 17:41 |
| 1489 | Henrik | what I do to cause the error is make a ps file with postscript.r and then feed it directly to the printer. In windows I print directly to LPT1: to produce it. Under Linux I print it via LPR. | 24-Feb 17:41 |
| 1488 | Geomol | that = what | 24-Feb 17:40 |
| 1487 | Geomol | To do anything about it, we need to be able to reproduce that error, and see if we can figure out, that might solve it. A way to test different things is to edit the ps-files by hand. | 24-Feb 17:39 |
| 1486 | Henrik | an important detail: I don't think it's single print jobs of multiple pages that cause it, but rather multiple single page jobs. | 24-Feb 17:36 |
| 1485 | Henrik | so for the other bug: I mentioned earlier that some printers I tried it on directly, will cause the printer to pause after the first page is printed. Then I need to press paper feed or reset the printer to get the rest out. Using Printfile for Windows solves that, but that program is really old and I don't want to rely on it in the future if my project is moved to Linux clients. I suspect there is just one char missing at the end of the PS file, but I don't truly know what causes it. | 24-Feb 17:34 |
| 1484 | Geomol | Yes, it works in preview now. :-) | 24-Feb 17:34 |
| 1483 | Henrik | BTW: Does it work for you in preview.app? | 24-Feb 17:25 |
| 1482 | Henrik | go ahead :-) | 24-Feb 17:23 |
| 1481 | Geomol | Great! That's the version to use for now then. Maybe I should put an announce in that group? | 24-Feb 17:22 |
| 1480 | Henrik | tried a much bigger image. no problems at all. | 24-Feb 17:20 |
| 1479 | Henrik | much faster now and it works | 24-Feb 17:19 |
| 1478 | Henrik | oh, error 40 :-) | 24-Feb 17:17 |
| 1477 | Henrik | odd, GS won't eat it | 24-Feb 17:17 |
| 1476 | Geomol | Henrik, try with new version now: http://home.tiscali.dk/john.niclasen/postscript/postscript.r | 24-Feb 17:15 |
| 1475 | Geomol | Ok, I'll see, if I can make a faster insert... | 24-Feb 17:07 |
| 1474 | Geomol | ok :) | 24-Feb 17:07 |
| 1473 | Henrik | did that | 24-Feb 17:06 |
| 1472 | Geomol | Just uncomment after the trim in line 213. | 24-Feb 17:06 |
| 1471 | Henrik | now GS won't read the PS file, but the generation is much much faster. less than 0.5 secs | 24-Feb 17:06 |
| 1470 | Henrik | I'm trying to remove that code right now to see if it improves performance. | 24-Feb 17:05 |
| 1469 | Geomol | If the inserting is the problem, then I might be able to fix that with copy to another series in stead. Problem with insert is, when you have large series, it has to move the content down the memory. | 24-Feb 17:04 |
| 1468 | Henrik | yep, same thing without /update. | 24-Feb 17:03 |
| 1467 | Henrik | didn't try that with /update yet. will have to be sure | 24-Feb 17:03 |
| 1466 | Geomol | ok, the inserting of the newlines is the problem? | 24-Feb 17:03 |
| 1465 | Henrik | so I think there should be an option to leave that out, or by default not have it. I'm guessing most people want to generate and print PS file, rather than read and edit them by hand. | 24-Feb 17:02 |
| 1464 | Geomol | You say, you tried a local file, but did you change the load-image in postscript.r? | 24-Feb 17:02 |
| 1463 | Henrik | nope, it's the inserting part. the rest is taking no time at all. | 24-Feb 17:01 |
| 1462 | Henrik | will try to add some profiling hints | 24-Feb 16:59 |
| 1461 | Henrik | it does not, I tried a local file. 12 seconds. | 24-Feb 16:59 |
| 1460 | Geomol | My guess is, that it's the load-image/update that give you performance hit. Try change it! | 24-Feb 16:58 |
| 1459 | Geomol | It seems to work without the newlines, but then the ps file become difficult to enter with e.g. vim. That part is fast, I think. It only put in a newline for every 80 chars. | 24-Feb 16:58 |
| 1458 | Henrik | does it need to be done? | 24-Feb 16:54 |
| 1457 | Henrik | perhaps inserting in images is very slow? | 24-Feb 16:54 |
| 1456 | Henrik | perhaps it's equal in speed, I don't know. odd though, I can't see what's so slow about that code, other than the newline insertion thing | 24-Feb 16:53 |
| 1455 | Geomol | So this is very simple encoding. ASCII85 encoding is a bit more difficult, but will take up less space. | 24-Feb 16:52 |
| 1454 | Henrik | ok | 24-Feb 16:50 |
| 1453 | Henrik | when building the image data, how do you do that? or does ASCIIHexDecode do that? | 24-Feb 16:50 |
| 1452 | Geomol | If you look in postscript.r, I encode the image data in line 211-220. It's just normal hex written as ASCII, so you get '0'-'9' + 'A '-'F'. | 24-Feb 16:50 |
| 1451 | Geomol | Images are implemented in postscript.r using ASCIIHexDecode filter, which double the size of image data. It would be better to implement ASCII85, which does a 4:5 increase only. Also images are handled in something called dictionaries in PostScript. This require PostScript v. 2.0. | 24-Feb 16:48 |
| 1450 | Henrik | what do you do to translate the data? is it in mezzanine form? | 24-Feb 16:48 |
| 1449 | Henrik | perhaps 12 seconds with a local palms.jpg file | 24-Feb 16:47 |
| 1448 | Henrik | testing postscript generation | 24-Feb 16:47 |
| 1447 | Henrik | writing palms.jpg locally took 1 second | 24-Feb 16:46 |
| 1446 | Geomol | Try take a local copy of postscript.r and change the load-image to not do a /update. | 24-Feb 16:44 |
| 1445 | Henrik | will test with a local file soon | 24-Feb 16:44 |
| 1444 | Geomol | ok | 24-Feb 16:44 |
| 1443 | Henrik | tried several times, same result. | 24-Feb 16:44 |