X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox From: karl AT aspodata DOT se To: geda-user AT delorie DOT com Subject: Re: [geda-user] adventures using arrows (for documentation), or cross my lines In-reply-to: References: <20180702125528 DOT D32CF81F76FE AT turkos DOT aspodata DOT se> Comments: In-reply-to Roland Lutz message dated "Thu, 12 Jul 2018 16:06:17 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-Id: <20180712172330.33B1B8420410@turkos.aspodata.se> Date: Thu, 12 Jul 2018 19:23:30 +0200 (CEST) X-Virus-Scanned: ClamAV using ClamSMTP Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Roland Lutz: > On Mon, 2 Jul 2018, karl AT aspodata DOT se wrote: > > c, use same line width as horiz. line, and use round cap style, i.e. > > patch gschem/lepton-schematic so that they honor the cap style entry > > which is currently completely ignored and and an undocumented cap > > style is used instead (called "miter" in postscript), see [3]. > > "miter" is a join style, not a cap style. Cap styles are honored in path > objects, but they only effect the ends of the path and don't have any > effect on closed paths at all. Correct. > > I'd prefer c to happen, since that would solve other line corner to > > straight line situations. > > I agree that it is preferable to solve this "properly", but cap styles > aren't going to help here. IMHO, gEDA/gaf should be trying to be as > "standard" as possible here and allow the user to specify a PostScript > join style. Great. Ps and cairo has matching names of calls and settings for line cap, join and miter limit; geda only has for line caps. One way to solve this would be to match line caps and line joins: end none (butt cap style) --- line join bevel end square --- line join miter end round --- line join round That would suffice for me. > This would mean adding an additional field to box and path objects. > Adding fields to the file format has been done before, it should be > considered carefully but can be done. > > > How difficult is that to implement and would such a patch be accepted ? > > Implementing this would be a bit finicky but possible. The problem here > is not to produce a working patch but to consider all the implications in > the different places that would be affected. Since this makes reviewing > such a patch almost as bad as writing it in the first place, I don't think > submitting a patch will help. My guess is that the path diretive is only used within symbols. Looking through cvs.gedasymbols I found 103 (out of 2577) symbols with paths. $ find /Net/cvs/cvs.gedasymbols.org/www/user/ -type f -name \*.sym -print0 | > xargs -0 grep -l "^H " | wc -l 85 $ find /Net/cvs/cvs.gedasymbols.org/www/user/ -type f -name \*.sym | wc -l 2577 In all cases, except for theese 33: edward_hennessy/symbols/ech-regulator-current-1.sym edward_hennessy/symbols/ech-diode-schottky-1.sym edward_hennessy/symbols/ech-diode-schottky-2.sym edward_hennessy/symbols/ech-diode-tvs-1.sym edward_hennessy/symbols/ech-diode-tvs-2.sym edward_hennessy/symbols/ech-diode-zener-1.sym edward_hennessy/symbols/ech-diode-zener-2.sym edward_hennessy/symbols/ech-fuse-resettable-1.sym edward_hennessy/symbols/ech-fuse-resettable-2.sym edward_hennessy/symbols/ech-switch-momentary-no-3.sym edward_hennessy/symbols/ech-switch-momentary-no-4.sym edward_hennessy/symbols/ech-resistor-1.sym edward_hennessy/symbols/ech-resistor-2.sym edward_hennessy/symbols/ech-opamp-ti-lmv324idr-5.sym edward_hennessy/symbols/ech-transistor-npn-prebiased-1.sym edward_hennessy/symbols/ech-opamp-ti-lmv324idr-3.sym edward_hennessy/symbols/ech-opamp-ti-opa2348aid-1.sym edward_hennessy/symbols/ech-opamp-ti-opa2348aid-5.sym edward_hennessy/symbols/ech-thyristor-scr-1.sym edward_hennessy/symbols/ech-diode-littelfuse-smaj5.0a-1.sym edward_hennessy/symbols/ech-transistor-pnp-1.sym edward_hennessy/symbols/ech-ground-analog-1.sym edward_hennessy/symbols/ech-transistor-pnp-prebiased-1.sym edward_hennessy/symbols/ech-ground-chassis-1.sym edward_hennessy/symbols/ech-ground-digital-1.sym edward_hennessy/symbols/ech-ground-signal-1.sym edward_hennessy/symbols/ech-led-nichia-nesm026d-1.sym edward_hennessy/symbols/ech-thyristor-scr-2.sym edward_hennessy/symbols/ech-transistor-mosfet-nch-enh-dio-1.sym edward_hennessy/symbols/ech-transistor-mosfet-nch-dep-dio-1.sym edward_hennessy/symbols/ech-transistor-mosfet-pch-enh-dio-1.sym edward_hennessy/symbols/ech-diode-littelfuse-sm24canb-1.sym edward_hennessy/symbols/ech-opamp-ti-lmv324idr-1.sym the path operator is used for filled arrows (solid fill except for one case of a mesh filled arrow). $ find /Net/cvs/cvs.gedasymbols.org/www/user/ -type f -name \*.sym -print0 | > xargs -0 grep -l '^H ' | grep -v edward | xargs grep -h "^H " | > sort | uniq -c 56 H 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 4 26 H 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 5 1 H 3 0 0 0 -1 -1 2 -1 -1 -1 -1 -1 5 5 H 6 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 4 I.e. everybody (other than Ed) uses filled paths with a line "width" of 0, and they use it for arrow tips. Filled arrow case definitely gain by having width = 0 => actual width = 0 so that the arrow tip doesn't go too far. I'd like filled paths with width to have a width of 0, and to be able to have round line join style. So we could ask Edward for his opinion. Ed, what is your take on this ? ... > As an immediate solutiuon to your problem, I suggest moving the arrow > object up a bit. If you set a non-zero line width, the bottom tip of the > arrow is well-defined, so if you wanted to, you could even calculate the > perfect offset by which to move the arrow up. Already done so. Regards, /Karl Hammar ----------------------------------------------------------------------- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57