You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(35) |
Jun
(11) |
Jul
(41) |
Aug
(96) |
Sep
(29) |
Oct
(44) |
Nov
(70) |
Dec
(61) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(126) |
Feb
(31) |
Mar
(64) |
Apr
(84) |
May
(57) |
Jun
(56) |
Jul
(20) |
Aug
(23) |
Sep
(31) |
Oct
(19) |
Nov
(60) |
Dec
(34) |
2003 |
Jan
(30) |
Feb
(61) |
Mar
(32) |
Apr
(30) |
May
(78) |
Jun
(55) |
Jul
(111) |
Aug
(108) |
Sep
(104) |
Oct
(98) |
Nov
(92) |
Dec
(73) |
2004 |
Jan
(71) |
Feb
(70) |
Mar
(68) |
Apr
(40) |
May
(118) |
Jun
(51) |
Jul
(71) |
Aug
(251) |
Sep
(77) |
Oct
(155) |
Nov
(74) |
Dec
(57) |
2005 |
Jan
(183) |
Feb
(94) |
Mar
(170) |
Apr
(242) |
May
(233) |
Jun
(42) |
Jul
(69) |
Aug
(70) |
Sep
(99) |
Oct
(60) |
Nov
(65) |
Dec
(210) |
2006 |
Jan
(169) |
Feb
(99) |
Mar
(31) |
Apr
(179) |
May
(142) |
Jun
(72) |
Jul
(131) |
Aug
(98) |
Sep
(110) |
Oct
(189) |
Nov
(262) |
Dec
(207) |
2007 |
Jan
(376) |
Feb
(255) |
Mar
(168) |
Apr
(174) |
May
(167) |
Jun
(192) |
Jul
(197) |
Aug
(171) |
Sep
(307) |
Oct
(572) |
Nov
(454) |
Dec
(471) |
2008 |
Jan
(707) |
Feb
(365) |
Mar
(464) |
Apr
(410) |
May
(251) |
Jun
(142) |
Jul
(112) |
Aug
(143) |
Sep
(94) |
Oct
(280) |
Nov
(337) |
Dec
(232) |
2009 |
Jan
(508) |
Feb
(491) |
Mar
(363) |
Apr
(280) |
May
(186) |
Jun
(250) |
Jul
(231) |
Aug
(487) |
Sep
(189) |
Oct
(344) |
Nov
(456) |
Dec
(439) |
2010 |
Jan
(514) |
Feb
(725) |
Mar
(591) |
Apr
(256) |
May
(209) |
Jun
(75) |
Jul
(118) |
Aug
(248) |
Sep
(230) |
Oct
(393) |
Nov
(368) |
Dec
(276) |
2011 |
Jan
(457) |
Feb
(308) |
Mar
(358) |
Apr
(277) |
May
(333) |
Jun
(320) |
Jul
(198) |
Aug
(186) |
Sep
(87) |
Oct
(238) |
Nov
(123) |
Dec
(129) |
2012 |
Jan
(127) |
Feb
(182) |
Mar
(208) |
Apr
(134) |
May
(230) |
Jun
(138) |
Jul
(126) |
Aug
(176) |
Sep
(231) |
Oct
(235) |
Nov
(164) |
Dec
(219) |
2013 |
Jan
(316) |
Feb
(371) |
Mar
(393) |
Apr
(165) |
May
(321) |
Jun
(301) |
Jul
(124) |
Aug
(183) |
Sep
(191) |
Oct
(285) |
Nov
(172) |
Dec
(196) |
2014 |
Jan
(392) |
Feb
(284) |
Mar
(134) |
Apr
(206) |
May
(123) |
Jun
(115) |
Jul
(41) |
Aug
(157) |
Sep
(122) |
Oct
(124) |
Nov
(63) |
Dec
(56) |
2015 |
Jan
(249) |
Feb
(335) |
Mar
(277) |
Apr
(98) |
May
(274) |
Jun
(214) |
Jul
(142) |
Aug
(240) |
Sep
(57) |
Oct
(77) |
Nov
(18) |
Dec
(171) |
2016 |
Jan
(217) |
Feb
(167) |
Mar
(62) |
Apr
(180) |
May
(270) |
Jun
(86) |
Jul
(112) |
Aug
(50) |
Sep
(57) |
Oct
(91) |
Nov
(62) |
Dec
(101) |
2017 |
Jan
(116) |
Feb
(115) |
Mar
(85) |
Apr
(35) |
May
(54) |
Jun
(123) |
Jul
(65) |
Aug
(35) |
Sep
(103) |
Oct
(28) |
Nov
(21) |
Dec
(7) |
2018 |
Jan
(27) |
Feb
(64) |
Mar
(42) |
Apr
(72) |
May
(49) |
Jun
(24) |
Jul
(18) |
Aug
(4) |
Sep
(9) |
Oct
(39) |
Nov
(11) |
Dec
(45) |
2019 |
Jan
(35) |
Feb
(24) |
Mar
(28) |
Apr
(38) |
May
(16) |
Jun
(41) |
Jul
|
Aug
(49) |
Sep
(41) |
Oct
(22) |
Nov
(15) |
Dec
(32) |
2020 |
Jan
(61) |
Feb
(3) |
Mar
(31) |
Apr
(29) |
May
(38) |
Jun
(16) |
Jul
(26) |
Aug
(87) |
Sep
(12) |
Oct
(4) |
Nov
(14) |
Dec
(5) |
2021 |
Jan
(3) |
Feb
(4) |
Mar
(26) |
Apr
(2) |
May
(55) |
Jun
(64) |
Jul
(96) |
Aug
(71) |
Sep
(1) |
Oct
(2) |
Nov
(17) |
Dec
(5) |
2022 |
Jan
(23) |
Feb
(22) |
Mar
(9) |
Apr
(7) |
May
(8) |
Jun
(6) |
Jul
(2) |
Aug
|
Sep
(14) |
Oct
(10) |
Nov
(1) |
Dec
(10) |
2023 |
Jan
(3) |
Feb
|
Mar
|
Apr
(34) |
May
(14) |
Jun
(25) |
Jul
(10) |
Aug
(13) |
Sep
|
Oct
|
Nov
(2) |
Dec
(7) |
2024 |
Jan
(1) |
Feb
(23) |
Mar
(33) |
Apr
(19) |
May
(5) |
Jun
(46) |
Jul
(2) |
Aug
(7) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
From: Alex R. <sh...@al...> - 2004-03-26 21:01:58
|
On Mon, 2004-03-22 at 11:14, Stian Jordet wrote: > man, 22.03.2004 kl. 18.46 skrev Alex Roitman:=20 > > What are the thoughts about the PDF creation in the future gramps? >=20 > Hmm. I seem to be the only one with that problem, but if I can't make A0 > pdf's with gnome-print, I will truly miss the reportlab plugin. >=20 > <optimistic> > Or are you maybe doing progress with that? :) > </optimistic> Not really much progress here. But there seem to be no good reason to drop support for reportlab right now. Well, I'm not being 100% true here :-) There's a reason for dropping reportlab: it's table support is only for rectangular table grid. in other words, cells spanning two columns are not supported. One needs to either work around with nested tables, or not use their table support and just reproduce the same thing that is done in gnome-print plugin. But all in all, the reportlab is here to stay for quite some time. I also thinks it's wise to support it, simply because for space-conscious latin-only users it offers a huge savings in file size, because of not embedding the fonts. Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Alex R. <sh...@al...> - 2004-03-26 18:43:23
|
Henry, Thanks for sharing your stuff. I haven't had a chance to look at it yet, but I wanted to mention another way of producing HTML output directly from GRAMPS XML data. Take a look at http://gramps.sourceforge.net/wiki/index.php/XSLTools It contains the XSL tools which can be applied directly to the XML file. By modifying these tools, one can get the desired HTML output. One needs xsltproc to operate on these XSL files. Alex On Fri, 2004-03-26 at 11:19, Henry Hartley wrote: > A while back I wrote a small web app (in Perl) that displays genealogical > data from a simple database. One thing I never got around to was writing= a > system for data entry. I coded the data I had at the time into a > spreadsheet and then imported that into the database, not the most effici= ent > or user friendly approach. Off and on since then I've done bits and piec= es > towards creating a data entry piece but never really got it working. It > would still be nice to have something that allows data entry through a > browser since that will allow users on any platform to do data entry > (assuming you trust your users). Recently, however, I've been looking at > GRAMPS and installed it last weekend. It looks quite good and I'm certai= nly > more likely to use it for data entry than what I've been doing. I wrote = a > script that dumped my database data into gramps compliant XML and can now= do > my data entry there. >=20 > The next step is to either write a script that will move the data back to= my > database for web viewing or modify my web app to use the XML directly. > Then, I could use GRAMPS for data entry and still view the data on the we= b. > I have never written anything in Python but this might be the excuse I ne= ed > to learn and I could convert my web script to a python script. I underst= and > that this is not the same thing as a GRAMPS plug-in and I don't know enou= gh > about GRAMPS yet to do that (even if I knew Python). One thing at a time= . > At this point, I'm not really volunteering to work on this Advanced Web P= age > plug-in since there are too many differences between what I've done and w= hat > needs doing. >=20 > In any case, I've put together a sample of what my system looks like for > those who are interested in putting a family tree on the web. It can be > found here: > <http://www.dotrose.com/cgi-bin/misc/familytree/tree.pl?page=3Dmain&id=3D= 1>. > With all the concern over privacy of personal information, I've populated= a > demo version of the database with a few English kings and their families. > It only has a few generations of data and even the data that is there is > incomplete (i.e. only four of Henry VIII wives) and possibly not even > accurate, but it should be enough to give you an idea of how the system > works. >=20 > Personally, I like my navigational approach (well, I would, wouldn't I?) > where you see a family at a time based around either a couple (with their > parents and children) or an individual (and their parents). Click on a > person's name to "center" that individual. This includes swapping spouse= s > left to right. For instance, click on Arthur Tudor. You will see him > alongside his wife, Katherine of Aragon. Now click on Katherine and you > will see her with her two marriages (Arthur first and then his younger > brother Henry). Now click on Henry and you will see the first four of hi= s > marriages. >=20 > It's certainly not complete and there is a lot of GRAMPS data that it won= 't > yet support but I wrote most of it back in 2001. Anyway, I'd be interest= ed > in your feedback and constructive criticism of my system. If I can make = it > work directly from GRAMPS data and include all the various data elements = it > might become quite useful to GRAMPS users. --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Henry H. <hen...@we...> - 2004-03-26 17:20:15
|
>> -----Original Message----- >> From: Alex Roitman [mailto:sh...@al...] >> Sent: Wednesday, March 24, 2004 4:28 PM >> >> GRAMPS project announces the $100 bounty for creating an Advanced >> Web Page plugin for gramps. The new plugin will allow producing >> the advanced web sites aiming at the best presentation of the >> genealogical data. A while back I wrote a small web app (in Perl) that displays genealogical data from a simple database. One thing I never got around to was writing a system for data entry. I coded the data I had at the time into a spreadsheet and then imported that into the database, not the most efficient or user friendly approach. Off and on since then I've done bits and pieces towards creating a data entry piece but never really got it working. It would still be nice to have something that allows data entry through a browser since that will allow users on any platform to do data entry (assuming you trust your users). Recently, however, I've been looking at GRAMPS and installed it last weekend. It looks quite good and I'm certainly more likely to use it for data entry than what I've been doing. I wrote a script that dumped my database data into gramps compliant XML and can now do my data entry there. The next step is to either write a script that will move the data back to my database for web viewing or modify my web app to use the XML directly. Then, I could use GRAMPS for data entry and still view the data on the web. I have never written anything in Python but this might be the excuse I need to learn and I could convert my web script to a python script. I understand that this is not the same thing as a GRAMPS plug-in and I don't know enough about GRAMPS yet to do that (even if I knew Python). One thing at a time. At this point, I'm not really volunteering to work on this Advanced Web Page plug-in since there are too many differences between what I've done and what needs doing. In any case, I've put together a sample of what my system looks like for those who are interested in putting a family tree on the web. It can be found here: <http://www.dotrose.com/cgi-bin/misc/familytree/tree.pl?page=main&id=1>. With all the concern over privacy of personal information, I've populated a demo version of the database with a few English kings and their families. It only has a few generations of data and even the data that is there is incomplete (i.e. only four of Henry VIII wives) and possibly not even accurate, but it should be enough to give you an idea of how the system works. Personally, I like my navigational approach (well, I would, wouldn't I?) where you see a family at a time based around either a couple (with their parents and children) or an individual (and their parents). Click on a person's name to "center" that individual. This includes swapping spouses left to right. For instance, click on Arthur Tudor. You will see him alongside his wife, Katherine of Aragon. Now click on Katherine and you will see her with her two marriages (Arthur first and then his younger brother Henry). Now click on Henry and you will see the first four of his marriages. It's certainly not complete and there is a lot of GRAMPS data that it won't yet support but I wrote most of it back in 2001. Anyway, I'd be interested in your feedback and constructive criticism of my system. If I can make it work directly from GRAMPS data and include all the various data elements it might become quite useful to GRAMPS users. -- Henry Hartley |
From: Don A. <dal...@us...> - 2004-03-26 15:56:10
|
Leonid Mamtchenkov wrote: >Good day everyone, > >I am interested in working on Advanced Web-Page plugin for Gramps. I am >planning on starting from existing code and removing/adding stuff based >on it. My knowledge of Python is mostly non-existing, but I am ready to >learn, so any help will be much appreciated. :) > > Leonid, Thanks for signing up for this. If you have any questions, don't hesitate to ask. Don |
From: Leonid M. <le...@le...> - 2004-03-26 11:06:59
|
Good day everyone, I am interested in working on Advanced Web-Page plugin for Gramps. I am planning on starting from existing code and removing/adding stuff based on it. My knowledge of Python is mostly non-existing, but I am ready to learn, so any help will be much appreciated. :) Any wishes except for those outlined in the wiki? :) -- Leonid Mamtchenkov. http://www.leonid.maks.net |
From: Alex R. <sh...@al...> - 2004-03-24 21:28:14
|
Dear fellow gramps users and developers: GRAMPS project announces the $100 bounty for creating an Advanced Web =20 Page plugin for gramps. The new plugin will allow producing the =20 advanced web sites aiming at the best presentation of the genealogical =20 data. While $100 may not be a tremendous amount, it should buy a few books, =20 quite a bit of pizza, a new disk drive, or the subscription to the =20 20000 slashdot pages without ads. The requirements for the plugin are listed at http://gramps.sourceforge.net/wiki/index.php/AdvancedWebPageBounty Interested people should contact gra...@li... mailing =20 list. Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Stian J. <li...@jo...> - 2004-03-22 21:19:56
|
man, 22.03.2004 kl. 18.46 skrev Alex Roitman: > Don, > > On 03/22/2004 11:11:15 AM, Don Allingham wrote: > > Direct printing and print preview is a major new enhancement to the > > project. I will try to post screenshots later this evening. > > I was thinking about the earlier plans to obsolete reportlab's PDF > plugin and the PS plugin. Now that we have a working gnome-print > plugin, I'm starting to doubt whether we should remove reportlab and > PS, even when LPRDoc becomes production quality in the future. > > The reason is that, being fully internationalized, gnome-print embeds > the fonts within PS/PDF. This is about the only choice for non-latin > output, but is a huge overhead for latin-only contents. > > As Frode Jemtland noticed, the latin-only PDFs created with reportlab > are a lot smaller than the ones created by LPRDoc. > > So, the question for the near future is: whether we want to have one > way of creating PDFs (gnome-print) and pay the unnecessary overhead > when using latin text, or whether we leave an option for latin contents > to use reportlab plugin producing leaner PDFs. The reportlab is an > extra dependency, of course. > > I personally would keep both. Since they're plugins, not having the > appropriate backend (reportlab or gnomeprint) would rule out using the > corresponding plugin. That way the users can always choose the backend > fitting their needs. > > As always, the trade-off is between the choice versus user-intuitive > setup. With too many choices things quickly become confusing, > especially for the new users. > > What are the thoughts about the PDF creation in the future gramps? Hmm. I seem to be the only one with that problem, but if I can't make A0 pdf's with gnome-print, I will truly miss the reportlab plugin. <optimistic> Or are you maybe doing progress with that? :) </optimistic> Best regards, Stian |
From: Alex R. <sh...@al...> - 2004-03-22 20:59:48
|
Don, On 03/22/2004 11:11:15 AM, Don Allingham wrote: > Direct printing and print preview is a major new enhancement to the > project. I will try to post screenshots later this evening. I was thinking about the earlier plans to obsolete reportlab's PDF plugin and the PS plugin. Now that we have a working gnome-print =20 plugin, I'm starting to doubt whether we should remove reportlab and =20 PS, even when LPRDoc becomes production quality in the future. The reason is that, being fully internationalized, gnome-print embeds =20 the fonts within PS/PDF. This is about the only choice for non-latin =20 output, but is a huge overhead for latin-only contents. As Frode Jemtland noticed, the latin-only PDFs created with reportlab =20 are a lot smaller than the ones created by LPRDoc. So, the question for the near future is: whether we want to have one =20 way of creating PDFs (gnome-print) and pay the unnecessary overhead =20 when using latin text, or whether we leave an option for latin contents =20 to use reportlab plugin producing leaner PDFs. The reportlab is an =20 extra dependency, of course. I personally would keep both. Since they're plugins, not having the =20 appropriate backend (reportlab or gnomeprint) would rule out using the =20 corresponding plugin. That way the users can always choose the backend =20 fitting their needs. As always, the trade-off is between the choice versus user-intuitive =20 setup. With too many choices things quickly become confusing, =20 especially for the new users. What are the thoughts about the PDF creation in the future gramps? Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Don A. <dal...@us...> - 2004-03-22 18:25:35
|
Alex Roitman wrote: > I was thinking about the earlier plans to obsolete reportlab's PDF > plugin and the PS plugin. Now that we have a working gnome-print > plugin, I'm starting to doubt whether we should remove reportlab and > PS, even when LPRDoc becomes production quality in the future. > > The reason is that, being fully internationalized, gnome-print embeds > the fonts within PS/PDF. This is about the only choice for non-latin > output, but is a huge overhead for latin-only contents. > > As Frode Jemtland noticed, the latin-only PDFs created with reportlab > are a lot smaller than the ones created by LPRDoc. > > So, the question for the near future is: whether we want to have one > way of creating PDFs (gnome-print) and pay the unnecessary overhead > when using latin text, or whether we leave an option for latin > contents to use reportlab plugin producing leaner PDFs. The reportlab > is an extra dependency, of course. > > I personally would keep both. Since they're plugins, not having the > appropriate backend (reportlab or gnomeprint) would rule out using > the corresponding plugin. That way the users can always choose the > backend fitting their needs. Maintaining the PDFDoc.py interface is actually a small effort. The installation issue has always been the bigger problem. ReportLab seems to be nicely packaged only for debian, so most people do not use it. The gnome-print option will provide PDF for a larger audience, since the needed libraries should all be installed together (starting with gnome-python 2.0 or greater). So, I guess what I'm trying to say is that I agree that keeping the current PDF generation is probably a good idea. Don |
From: Don A. <dal...@us...> - 2004-03-22 17:32:41
|
Don Allingham wrote: > The GNOME print interface has been completed due to the efforts of > Billy Earny and Alex Roitman. Alex, being one of the two project > managers, is ineligible for the bounty. Billy Earny has requested that > portion of the bounty be put back into the bounty program. Sorry, I had a typo here. Billy has requested that his entire portion of the bounty be returned back to the bounty program. After reading what I originally wrote, I realized that it could easily be misinterpreted. Don |
From: Don A. <dal...@us...> - 2004-03-22 17:11:24
|
The GNOME print interface has been completed due to the efforts of Billy Earny and Alex Roitman. Alex, being one of the two project managers, is ineligible for the bounty. Billy Earny has requested that portion of the bounty be put back into the bounty program. I'd like to thank both Alex and Billy for the work that they did. Direct printing and print preview is a major new enhancement to the project. I will try to post screenshots later this evening. We are about to set up the second bounty. We have decided that this should be for the Advanced Web Page generator that has been discussed to quite an extent on the mailing lists. More details will follow soon. Don |
From: Alex R. <sh...@al...> - 2004-03-19 23:33:48
|
On 03/18/2004 06:29:11 PM, Alex Roitman wrote: > I will update the translation template as soon as I am done with the =20 > last tweaks, and send another announcement when I have done so. At this point, translatable strings should be consider frozen. No=20 changes to the strings should be committed, barring only major bug=20 fixes. Translators: the new template.po is in the STABLE branch of the CVS. If=20 you have trouble switching to the stable CVS tree, feel free to send=20 your questions and you will be helped :-) As a backup, you may also=20 grab template.po from the following place: http://cvs.sourceforge.net/viewcvs.py/*checkout*/gramps/gramps2/src/po/temp= late.po?rev=3D1.56.2.2 Let's make a deadline of Wednesday, March 31 for the translated po=20 files. Again, if you have troubles committing your translation to=20 STABLE branch, email it to Don. I'm going to be away for a couple=20 of weeks, so emailing it to me might not do the trick this time. Manual translators: there's few changes in the manual, see my previous=20 email. Let's obey the same deadline of March 31, so that Don can build=20 and test packages in time for upload on April 2. I'm going to be responsive until March 27. Please let me or Don know=20 if you have questions. Thanks, Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Alex R. <sh...@al...> - 2004-03-19 16:13:46
|
On 03/19/2004 04:59:10 AM, Tim Waugh wrote: > On Thu, Mar 18, 2004 at 06:29:11PM -0600, Alex Roitman wrote: >=20 > I don't really see why you need a special font for this -- just use > pango and it will select an appropriate font with the right coverage > for each character: >=20 > http://www.pango.org/font-selection.shtml Maybe you're right, but I don't know how to use pango with gnome-=20 print :-) The examples in gnome-print source say nothing about pango. =20 If you could point me to some reference I would be most grateful. Another problem is that there are only two sets of true type fonts with =20 the more-or-less complete UCS coverage: MS and freefont. With either =20 set we don't have to worry about covering individual characters. Added =20 together with the fact that we are not allowing the user to control the =20 font (it's supplied by the paragraph style) pango would not be a great =20 asset, it seems to me. The current behavior of LPRDoc is to look for freefont first. If it is =20 not found then it looks for MS fonts. If those are not found then it =20 uses Sans, Serif, and Monospace. Those are guaranteed to exist in gnome =20 environment, are true type, but cover latin script only. For anything other than latin script, whether we use pango or some =20 other way of smartly selecting the font, the choice will always be =20 between MS and freefont. Having freefont available just simplifies the =20 matters. I might be missing something, as always, so I'd be happy to learn how =20 to do it right :-) Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Tim W. <tw...@re...> - 2004-03-19 10:59:28
|
On Thu, Mar 18, 2004 at 06:29:11PM -0600, Alex Roitman wrote: > Also, as was recently discussed on gramps-users, we would like to > highly recommend freefont-ttf package to have sane unicode output > with printing plugin and GraphViz. The reasonable approach seems to > require freefont-ttf in the enviroments where freefont-ttf is > available from the same repository as gramps (eg. apt repo for SuSE > by Richard Bos), and recommend it by printing text upon postinstall > in other Benvironments (Mandrake, RH/Fedora). I don't really see why you need a special font for this -- just use pango and it will select an appropriate font with the right coverage for each character: http://www.pango.org/font-selection.shtml As far as RPM goes, it isn't really appropriate to display any message in the %post scriptlet, since it often won't be seen by anything but a program. It's not for interaction with users. If you must do this kind of thing it's better to do it on per-user first runtime invocation or something. Tim. */ |
From: Alex R. <sh...@al...> - 2004-03-19 04:06:28
|
On Thu, Mar 18, 2004 at 10:55:17PM -0500, James A. Treacy wrote: > >=20 > The next upload will contain Recommends: ttf-freefont Great, thanks! > As for python-reportlab and python-imaging they have been dependencies > for a number of releases. The current dependencies are: > Depends: python2.3-gnome2, python2.3-glade2, python2.3-reportlab, > python2.3-imaging, gramps-common (>=3D 1.0.1-1), scrollkeeper You're right. I've been mistakenly looking at gramps-common and did not see those, sorry. Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: James A. T. <tr...@de...> - 2004-03-19 03:55:20
|
On Thu, Mar 18, 2004 at 06:29:11PM -0600, Alex Roitman wrote: > > In debian, we can recommend ttf-freefont (that's how it's called in > debian). James, while you're at it, why don't you also recommend > python-reportlab (or python2.3-reportlab ?) and python-imaging > (python2.3-imaging?) packages? > The next upload will contain Recommends: ttf-freefont As for python-reportlab and python-imaging they have been dependencies for a number of releases. The current dependencies are: Depends: python2.3-gnome2, python2.3-glade2, python2.3-reportlab, python2.3-imaging, gramps-common (>= 1.0.1-1), scrollkeeper -- James (Jay) Treacy tr...@de... |
From: Alex R. <sh...@al...> - 2004-03-19 00:29:14
|
Hi, The new release from STABLE branch is coming up. It will feature some =20 bug fixes in the reports, enhancements to the Web page (configurable =20 depth for mini-tree and alt tag for images by Leonid Mamtchenkov; =20 uniform thumbnail sizes, optional birth years/full dates appended to =20 the names on the index page), two new report format plugins (plain text =20 and gnome-print based), and two more translations of the manual: German =20 (Sebastian V=F6cking) and Hungarian (Egyeki Gergely). Let's try to release around April 2, which is two week from now. I will =20 update the translation template as soon as I am done with the last =20 tweaks, and send another announcement when I have done so. This is just to give everybody an update so that translators and =20 packagers can plan their time. Also, as was recently discussed on gramps-users, we would like to =20 highly recommend freefont-ttf package to have sane unicode output with =20 printing plugin and GraphViz. The reasonable approach seems to require =20 freefont-ttf in the enviroments where freefont-ttf is available from =20 the same repository as gramps (eg. apt repo for SuSE by Richard Bos), and recommend it by printing text upon postinstall in other =20 environments (Mandrake, RH/Fedora). In debian, we can recommend ttf-freefont (that's how it's called in =20 debian). James, while you're at it, why don't you also recommend =20 python-reportlab (or python2.3-reportlab ?) and python-imaging =20 (python2.3-imaging?) packages? There hasn't been a lot of changes in the interface or the core of =20 gramps, so the manual does not have to change. If I am mistaken, please =20 point me to the places that need to be documented. Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Alex R. <sh...@al...> - 2004-03-17 01:50:45
|
Lars, On Fri, Mar 12, 2004 at 12:09:28PM -0000, Lars Kr.Lundin wrote: >=20 > Otherwise I propose that someone rename da_DK.po to da.po in the > CVS and takes any other steps necessary to put this change into effect. > (I assume I do not have privilege to do it). This should be done in STABLE CVS branch. Let me know if something is wrong. BTW, I think you do have all the privileges to do that, so feel free to add/remove files in CVS if necessary. Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Egyeki G. <eg...@el...> - 2004-03-16 09:12:14
|
On Thu, 11 Mar 2004, Laurent Protois wrote: > Hi, [...] > > I know i have so much places on my database ;-) > > Notes : I have done new contribs of places, > in utf8 ;-))) > see : http://laurent.protois.free.fr/Gramps/ > > 1 - in Contrib : > files of places by countries,states,counties ... > > 2 - in Scripts : > a little script to insert them in a data.gramps. > > Laurent Only an idea for the future: It's possible to add this places to the GRAMPS sources? So the user can browse between the places... Add/delete/modify this locals... Geri |
From: Stian J. <li...@jo...> - 2004-03-16 01:54:29
|
l=F8r, 13.03.2004 kl. 02.28 skrev Alex Roitman: > Stian, >=20 > On Sat, Mar 13, 2004 at 02:16:30AM +0100, Stian Jordet wrote: > > fre, 12.03.2004 kl. 18.49 skrev Alex Roitman: > > > Has anybody had a chance to try out the LPRDoc.py plugin? > > > I'm anxious to get some feedback, please send me some :-) > > >=20 > > > If you have tried it and it works for you, please say so :-) > >=20 > > Hmm. I just tried it very briefly. It seems to work well, but if I tr= y > > to make a PDF in A0 size, it can't be done. It looks like gnome-print > > only wants to use the available paper sizes from a selected printer. = If > > so, I guess that's a problem with gnome-print and not the plugin? >=20 > I am trying to figure out the gnome-print quirks at the moment (and > I have to tell you -- there's plenty :-) relating to proper paper size > settings. > > It is my (so far unconfirmed) impression that each backend (PDF, Generi= c > Postscript, CUPS system, and whatever else can work as a printing backe= nd) > has its own set of available paper sizes within gnomeprint. The selecti= on > list available for PDF is rather scarce, as you have noticed. >=20 > I don't know yet whether it is possible to set PDF paper size to A0 > in any way. It seems that it is possible with Generic postsrcipt backen= d. > I would imagine that ps2pdf or xpdf-related tools can convert such a=20 > postscript to PDF.=20 I tried using ps2pdf, but that gave a very, very unexpected result. The ancestor chart was suddenly using greek characters (or something that looked like it), besides the chart was clipped, and was obviously not A0, even if I could choose that paper size. As I said, I understand that it is a Gnome bug that you can't make larger pdf's than A0 (or Letter), but should I file a bugreport at their bugzilla about it? And when talking about bugs... The ancestor chart pdf-report is now capable of creating files with the norwegian characters =E6=F8=E5. But th= e fan chart is not, for some reason. Except for me being unable to create A0 pdf's, the Gnome-print plugin works very good :) I do have one idea for a new feature, but I'm not sure you like it. Now one can scale charts to fit on one page. This is a very good feature, which Don actually made to satisfy me :) Problem is, that I can write a 10 generation chart to a A4 page, and it will be way to small to read. But if I select to not scale it, it actually becomes 100 pages, which is way to much. I would guess that 5-10 pages would have been enough to be able to read it. What I would love is an option to select how many pages it should fit on, not just one. Is this just crazy? Thanks for your always prompt response, and kind help, and sorry for always being so demanding without giving anything back. Best regards, Stian |
From: Egyeki G. <eg...@el...> - 2004-03-15 20:16:07
|
On Fri, 12 Mar 2004, Alex Roitman wrote: > Has anybody had a chance to try out the LPRDoc.py plugin? > I'm anxious to get some feedback, please send me some :-) > > If you have tried it and it works for you, please say so :-) > > For those who missed the previous call, the details are below. > > Thanks, > Alex Alex and Billy, This is great! For me work fine! Geri |
From: Alex R. <sh...@al...> - 2004-03-15 06:27:05
|
Hi, I ran sloccount on the stable gramps tree, and the results are below. Not sure what to make of it, but it surely sounds impressive. The question which comes to mind is where's that 1.6 mil :-) Kidding :-) Anyway, just wanted to share this with everybody, Alex Total Physical Source Lines of Code (SLOC) =3D 50,025 Development Effort Estimate, Person-Years (Person-Months) =3D 12.17 (146.00) (Basic COCOMO model, Person-Months =3D 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) =3D 1.38 (16.61) (Basic COCOMO model, Months =3D 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) =3D 8.79 Total Estimated Cost to Develop =3D $ 1,643,570 (average salary =3D $56,286/year, overhead =3D 2.40). SLOCCount is Open Source Software/Free Software, licensed under the FSF GPL. Please credit this data as "generated using 'SLOCCount' by David A. Wheeler= =2E" --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Leonid M. <le...@le...> - 2004-03-14 20:09:33
|
* Don Allingham <dal...@us...> [14-Mar-2004 08:27]: > > I think it should also be possible to specify a site-wide CSS file. So > > that instead of creating a new one with gramps, you could just say, use > > the style sheet with URL /css/gramps.css or something. > > The problem with an external style sheet that GRAMPS does not generate > is that GRAMPS does not know what styles have been defined in the style > sheet or to which paragraphs/elements they need to be applied. Gramps doesn't have to know which styles were defined and which were not. > We would have to carefully define the required styles that must be > defined in any external style sheet, and gracefully handle any that are > not there. I do see any problem here. It's just a matter of documenting the specs. Documentation should say that there is class "gallery-heading". It's up to the user to define it. Gramps would just insert class specification in the appropriate tag. That's it. -- Leonid Mamtchenkov. http://www.leonid.maks.net |
From: Don A. <dal...@us...> - 2004-03-14 15:28:09
|
On Sun, 2004-03-14 at 01:59, Leonid Mamtchenkov wrote: > " > - An external stylesheet file > > Current plugin uses stylesheets embedded in each file. A single external > stylesheet would save the space required for hosting the web site, and > would also make it easier to control the appearance of the whole site by > modifying a single CSS file. > " > > I think it should also be possible to specify a site-wide CSS file. So > that instead of creating a new one with gramps, you could just say, use > the style sheet with URL /css/gramps.css or something. The problem with an external style sheet that GRAMPS does not generate is that GRAMPS does not know what styles have been defined in the style sheet or to which paragraphs/elements they need to be applied. We would have to carefully define the required styles that must be defined in any external style sheet, and gracefully handle any that are not there. Don -- Don Allingham <dal...@us...> GRAMPS - Open Source Genealogy |
From: Frode J. <fro...@sk...> - 2004-03-14 09:15:08
|
Wednesday 10 March 2004 19:58, wrote Alex Roitman: > Hello everybody, > > The first draft of the gnome-print plugin written by Billy Earney and > myself is in CVS HEAD now. The following features are supported in the > direct printing/previewing: Alex and Billy, great work :) To get a quick preview of the reports this possibility is great. Really a feature I have been waiting for. The Print... option was on all expected reports. And it work very well. I compared different reports in pdf format made with the ReportLab plugin and with the new gnome-print plugin (we are talking real deep scientific research here :)) I don't know how any of these plugins work, or what I can expect gnome-print to do, so I don't know if this kind of comparisons actually tells me anything :) My _observations_ are that the ReportLab plugin generate smaller files (6-60 times), and in the most cases "nicer" pdf's, with right shadows, and more mathematical correct lines. Almost the same differens as in a raster and vector image...... I think I found an error in the fan chart report generated with the gnome-print. The text in my fan are missing. ReportLab: Size 31094, http://www.jemtland.com/~frode/fan_chart.pdf Gnome-print: Size 194305, http://www.jemtland.com/~frode/fan_chart-lprdoc.pdf Another ting I noticed was that when I choose the "Print..." option in a report, and hits the OK button, I'm asked if I want to overwrite the file that is in the "Filename" box. (If this file already exists.) But the file are not touched. Keep up the good work. GRAMPS : 1.0.1-1 LANG : no_NO.UTF-8 Python : 2.3.3 final GTK : 2.2.4 PyGTK : 2.0.0 Debian Sid -- -Frode To live is always desirable. -- Eleen the Capellan, "Friday's Child", stardate 3498.9 |