On Tue, 2009-06-09 at 02:30 +0000, Kai-Martin Knaak wrote: > On Tue, 09 Jun 2009 02:32:34 +0100, Peter Clifton wrote: > > > The only grief comes with the currently magic behaviour at 180 degrees, > > which basically resets to 0 degrees rotation, and flips the anchor point > > to the opposite corner of the text box. > > To me, this very magic is a grief. It tires to second guess how I want to > orient text in the schematics. Text is placed differently relative to the > mark when flipped. Took me quite some time to figure the logic behind > this seemingliy weird behaviour. I'd be happy to kiss it good bye.
Well.. flipping a text object - DOES flip its anchor - that is just what it does... I'm not going to give you backwards text. If you want magic - it will have to be magic which allows a component to be flipped, then uses some heuristic to put the text back. Text width is basically undefined until render time - so what you want isn't actually that easy. Actually, I'm starting to see some flaws in my cunning plan to remove the magic 180 degree flipping heuristic - relating to rotation of components. EVEN if we mimiced the 180 rotation by resetting back to 0, and moving the anchor point, you loose information about what the next rotation should be. At the very least, we could generalise the flipping action and make it operate for a range of angles where text appears partially upside-down. > > Font sizes give some grief as well. It would be nice if the on-screen > > font size matched the print font > > Yes, text on screen definitely should match printed text. Anything else > is a pain. All too often I need to place text so that it just fits. Well. I can make them the same; but we have two options: A. Match postscript point size - so a 10pt font prints / views as a 10pt font. (When printed on a title-block which matches the size of the paper - printed with no margin). This takes the definition of 1pt as 1/72 of an inch, and scales the fonts assuming gschem units are 1/1000th of an inch. (Oh - and this size doesn't actually correspond to anything explicitly measurable on the typeface, it is just the logical design height of the font). Screen sizes change (until we bump schematic schematics) Postscript sizes remain (until we bump schematic sizes) Conversion tools required to fix on-screen sizes. B. Redefine the units of gschem's font size, calling them 1/1.3 of a pt. This means that the new on-screen renderer applies the 1.3x scaling factor (internally), require to make the new fonts match (approximately) the same height as the old. Don't touch the printing code. This option has the disadvantage that we now have the same on-screen discrepancy in the printed output - which would remain (as is now), smaller than on-screen. Screen sizes remain Postscript sizes remain (but are different to on-screen - BAD) Please lets not do this one! C. Do B. above, but also bump the postscript output sizes by a factor of 1.3. This means screen and print are consistent, but that printing a schematic using new gschem will produce different sized fonts in its .ps output as compared to an old gschem. Screen sizes remain Postscript sizes bumped to match screen. Conversion warning about increased printed size? (Optional) Currently my cairo_experiment branch does "option B" above, but I want that to change in favour of either "A" or "B". > > 1. Within gschem - possibly via some nasty popup dialog / wizard when > > you load an old file. > > > > 2. Command line based - so old designs can be (if desired) batch > > updated. > > Number two would be reasonable. It should be supported by a big, fat > release note. Also, no-one can complain we didn't tell them if we popup a nag dialog when they start gschem. I'd (ab)use the window placement preferences file to remember whether the user asked it to die and never come back - either that, or invent yet another ~/.gEDA/ file, such as "version-migration", and save some data as to the user's upgrade preferences there. (As Steven suggested, we could store "Ask, Always, Never".) > > Or.. do we accept the on-screen shrinkage, and place greater value on > > consistency of .ps printed output from existing schematics? > > Please don't. This would add to the heap of feature cruft that tends to > make long lived software projects gradually more difficult for newbies to > grasp. You can't have your cake and eat it.. I firmly believe that we need to keep on-screen and printed schematics looking as close as possible. That means that gEDA 1.6.0 will either we keep the old on-screen, or the old printed sizes consistent. > Just my two ยข > > ---<(kaimartin)>--- > > > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
