From: <db...@br...> - 2006-02-18 22:01:14
|
All, I have updated Calendar.py and holidays.xml: ------ cd plugins wget http://bubo.brynmawr.edu/~dblank/python/Calendar.py wget http://bubo.brynmawr.edu/~dblank/python/holidays.xml ------ (code should say Revision 7). Details here: http://emergent.brynmawr.edu/emergent/GrampsCalendarReport Some things I encountered in generating reports: 1) The lines and text don't seem to line-up between all docgen types. Specifically, it seems that PDF is different from the others by having text draw 0.5 units higher (when compared to lines) than the others. I added an "offset" report option on the "Text Options" to allow people to move the text (but not boxes). 2) On the PostScript calendar, there is a black bar at the top. I don't know what that is. 3) In the OpenOffice version, paragraphs seem to have borders around the text, but these do not appear in the other versions. Some calendar notes: I added all of the suggestions for changes to the "US" section of the holidays (including Tax day, and easter). There aren't any other holidays for any other country. If people want to have holidays for their country, please send them to me, in your native language, in XML unicode (I guess)= , according to the above website rules. There are a few strings for translation in the program. Feel free to adjust those to match style or text of other reports. A Calendar-specific item: Most people don't want their full name, so I us= e the nick_name if there is one. You can print all maiden names, or use all married names. However, some people may want their maiden name to show; other may want to use their husband's name---regardless of the setting. So, if a nick_name has a space in it, then it will treat that as their firstname and lastname. Maybe there is a preferred last name option? Also, sometimes you can't select the people that you want using a builtin filter (although People with common ancestor, or Descendent Families usually works quite nicely). But I did add a filter that looks for the word "Calendar" in any field so that you could pick and choose who you want included. The holiday file can be in the global OR the personal gramps/plugin/ directory. Currently, it will process both if you have them (and mark the= m for inclusion). TODOs including making a text-only version, which should be quite easy. Please let me know of any issues. -Doug |
From: Eero T. <ee...@us...> - 2006-02-19 18:10:16
Attachments:
calendar-oo.png
|
Hi, On Sunday 19 February 2006 00:01, db...@br... wrote: > I have updated Calendar.py and holidays.xml: > > ------ > cd plugins > wget http://bubo.brynmawr.edu/~dblank/python/Calendar.py > wget http://bubo.brynmawr.edu/~dblank/python/holidays.xml > ------ > > (code should say Revision 7). Details here: > > http://emergent.brynmawr.edu/emergent/GrampsCalendarReport > > Some things I encountered in generating reports: I had large problems with the output formats: - PDF: - Looks otherwise OK, but all the texts and numbers are way too small compared to the calendar size - PS, A4 page size: - In portrait mode only bottom left corner of the calendar is visible - In landscape mode only top left corner of the calendar is visible - (old gnome-)print... -> PDF, A4 page size: - only top left corner of the calendar fits into page - Open Office: - In my old OO v.1.1.1, the text looks very strange, see attachment The output would look much better if the code would scale the calendar so that it fits into selected page size. The font size should also be scaled appropriately. Then it could be also printed. :-) - Eero |
From: <db...@br...> - 2006-02-19 20:19:23
|
> Hi, > > On Sunday 19 February 2006 00:01, db...@br... wrote: >> I have updated Calendar.py and holidays.xml: >> >> ------ >> cd plugins >> wget http://bubo.brynmawr.edu/~dblank/python/Calendar.py >> wget http://bubo.brynmawr.edu/~dblank/python/holidays.xml >> ------ >> >> (code should say Revision 7). Details here: >> >> http://emergent.brynmawr.edu/emergent/GrampsCalendarReport >> >> Some things I encountered in generating reports: > > I had large problems with the output formats: > - PDF: > - Looks otherwise OK, but all the texts and numbers are way too small > compared to the calendar size > - PS, A4 page size: > - In portrait mode only bottom left corner of the calendar is visible > - In landscape mode only top left corner of the calendar is visible > - (old gnome-)print... -> PDF, A4 page size: > - only top left corner of the calendar fits into page > - Open Office: > - In my old OO v.1.1.1, the text looks very strange, see attachment > > The output would look much better if the code would scale the calendar = so > that it fits into selected page size. The font size should also be sca= led > appropriately. Then it could be also printed. :-) Eero, Thanks for testing. The calendar code does scale the calendar to fit within the page width and height. The font-scaling is an interesting idea= , but I'd like to solve these other basic problems first. (Of course, you can change the font size in options). And, I hope that we can have a dynamic view of all reports so that you see changes on-the-fly. That woul= d make it easy for the human to set the right font. I don't think that the errors that you report are the fault of the calendar code. I believe that I don't hard-code any values---they are all based on font height and width and page height and width. It looks like those are problems somewhere else, unless there is something I'm not doin= g correctly. -Doug > > - Eero > |
From: Anthony J. S. <ant...@ie...> - 2006-02-21 15:49:30
Attachments:
calendar-new.pdf
calendar-old.pdf
|
The new version does not properly align the boxes in the .pdf output. I've attached the output of the Calendar plugin. calendar-old.pdf is from Calenday.py where __version__ = "$Id: 5 $" and calendar-new.pdf is from __version__ = "$Revision: 7 $". Tony |
From: Douglas S. B. <db...@br...> - 2006-02-21 19:35:35
|
Tony, Thanks for testing. Actually, you are experiencing the text offset that I described in the earlier email. The boxes are ok (I think); it is the text that is offset. If you set the text offset on the Text Options to be 0.0, then it will display fine on the PDF output. If you want it to display fine on the PS and OpenOffice output, then a value around -0.5 will align everything. Your comment does make me wonder now, though: which is correct, PDF or PS? Which is off, text or boxes? I'll have to actually takes some measurements on paper to find out... -Doug On Tue, 2006-02-21 at 08:49 -0700, Anthony Joseph Seward wrote: > The new version does not properly align the boxes in the .pdf output. > > I've attached the output of the Calendar plugin. calendar-old.pdf is > from Calenday.py where __version__ = "$Id: 5 $" and calendar-new.pdf is > from __version__ = "$Revision: 7 $". > > Tony > > > -- Douglas S. Blank Computer Science Assistant Professor Bryn Mawr College (610)526-6501 http://cs.brynmawr.edu/~dblank |
From: Alex R. <sh...@gr...> - 2006-02-23 01:10:31
|
Doug, On Sat, 2006-02-18 at 17:01 -0500, db...@br... wrote: > I have updated Calendar.py and holidays.xml: Don has added both files to the src/plugins and this is going to be shipped with gramps 2.0.10. I have just updated the Russian translation for 2.0.10 and noticed a few things: 1. The exception messages were translated. I have changed that to use English for Exceptions. The idea is that if the user does not understand the message then it's OK, because many would not understand the details even in their native language. As long as they send it to us it should do. Ideally users are not even supposed to see it :-) But adding an overhead of translating this text into all supported languages is probably not warranted. 2. It seems to me that values stored by Widgets under the valid_text and help keys are those that will be displayed in the command line help, are they not? If so, I would not translate them either. I feel less strongly about it, because these are not errors and can be routinely displayed by GRAMPS. However, in practice they are not always useful, because displaying them requires the terminal to display the particular charset, and this is not always a given. One can make an argument that if the user is running from the terminal then the user is aware of that and has the terminal that supports his/her charset. But one can also make an argument that English is guaranteed to be perfectly displayable everywhere, while other languages may not (cyrillic, chinese, japanese, etc). Most importantly, only few users seem to be using CLI at all. Those tend to be able to understand English enough to use the CLI and read man pages. So far our thinking was that the CLI users are fine with English only. The bottom line here is this: do we want some 25 translators to have to translate something that is used by probably less than 25 people? My answer to this would be a NO. Do you feel strongly about it? Does anybody else have an opinion on whether the CLI should use translated help strings (if you don't know what this all is about then you probably don't have an opinion). I would convert all those help strings to English unless there's some strong opposition voiced on this list. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: <db...@br...> - 2006-02-23 01:27:29
|
> Doug, > > On Sat, 2006-02-18 at 17:01 -0500, db...@br... wrote: >> I have updated Calendar.py and holidays.xml: > > Don has added both files to the src/plugins and this is going to > be shipped with gramps 2.0.10. Alex, Great! > I have just updated the Russian translation for 2.0.10 and > noticed a few things: > > 1. The exception messages were translated. I have changed > that to use English for Exceptions. The idea is that if > the user does not understand the message then it's OK, > because many would not understand the details even in > their native language. As long as they send it to us > it should do. Ideally users are not even supposed to see it :-) > But adding an overhead of translating this text into all > supported languages is probably not warranted. Fine by me. I think that is a good rule. > 2. It seems to me that values stored by Widgets under the > valid_text and help keys are those that will be displayed > in the command line help, are they not? If so, I would not [snip] I wasn't actually sure when and where those text items were shown; I thought they were tool tips, or something like that. Again, not convertin= g them is fine by me. Do you want me to remove the _() calls (if that is the decision)? Thanks! -Doug > Alex > > -- > Alexander Roitman http://www.gramps-project.org > |
From: Alex R. <sh...@gr...> - 2006-02-23 03:08:47
|
Doug, On Wed, 2006-02-22 at 20:27 -0500, db...@br... wrote: > > > > 1. The exception messages were translated. I have changed > > that to use English for Exceptions. The idea is that if > > the user does not understand the message then it's OK, > > because many would not understand the details even in > > their native language. As long as they send it to us > > it should do. Ideally users are not even supposed to see it :-) > > But adding an overhead of translating this text into all > > supported languages is probably not warranted. >=20 > Fine by me. I think that is a good rule. >=20 > > 2. It seems to me that values stored by Widgets under the > > valid_text and help keys are those that will be displayed > > in the command line help, are they not? If so, I would not >=20 > [snip] >=20 > I wasn't actually sure when and where those text items were shown; I > thought they were tool tips, or something like that. Again, not convertin= g > them is fine by me. Awesome! These strings should be shown when you run this in the CLI: $ gramps -O filename.grdb -a report -p name=3Dcalendar,show=3Dblah where "blah" is the option name. I haven't tested the calendar yet, but this is the intent for other reports and tools anyway. I think having these in English would be good (even though I've already translated mine :-( ) > Do you want me to remove the _() calls (if that is the decision)? I'll do it anyway, since I need to also regenerate and commit template.po Alex P.S. Although having a tooltip would not be a bad idea. The only thing is that maybe it should be optional? Some options are very clear, actually most of them are. In case something is not so clear a tooltip would be good. Something for us to think about. --=20 Alexander Roitman http://www.gramps-project.org |
From: Alex R. <sh...@gr...> - 2006-02-23 19:36:11
|
Doug, On Wed, 2006-02-22 at 20:27 -0500, db...@br... wrote: > Do you want me to remove the _() calls (if that is the decision)? I have removed those and committed the changes and the updated template.po file. In addition to the _() removal I made few cosmetic tweaks: 1. Remove 'import string' and change 'string.strip(data)' to 'data.strip()'. 2. Remove importing of SubstKeywords, Date, and DateHandler modules, seemingly unused. 3. Tweaked generic Widget's help and valid_text, to be more suitable for CLI help. Most likely this will never be seen by the user, but as long as there are some placeholders I figured it's better to have them fit their role. Let me know if any of those changes was in error and I'll fix it. I also have a question for you: was it your intention to mark the plugin as Unsupported? The idea of unsupported reports was that this category contains reports that may or may not be working, and which we do not care much about. Sort of contributed reports. We would ignore any bug reports on the unsupported reports and just tell the user that those are not what we suggest to use. As long as you're willing to cooperate on developing/fixing this report, I see no reason as marking is unsupported. Even if it's not bullet-proof stable (status can be used for that), we may ship it as supported and keep working on it. Finally, while we're at it, would you like to get write access to the CVS so that you don't need a middleman to commit the changes each time? If so, let me know your sourceforge user name and I'll add you to the devel list. Let me know what you think, Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Alexandre P. <ale...@gm...> - 2006-02-23 19:56:09
|
On 2/23/06, Alex Roitman wrote: > I have just updated the Russian translation for 2.0.10 and > noticed a few things: > > 1. The exception messages were translated. I have changed > that to use English for Exceptions. The idea is that if > the user does not understand the message then it's OK, > because many would not understand the details even in > their native language. As long as they send it to us > it should do. Ideally users are not even supposed to see it :-) > But adding an overhead of translating this text into all > supported languages is probably not warranted. Sounds good for me :) Alexandre |
From: Douglas S. B. <db...@br...> - 2006-02-24 20:25:17
|
On Thu, 2006-02-23 at 11:35 -0800, Alex Roitman wrote: > Doug, > > On Wed, 2006-02-22 at 20:27 -0500, db...@br... wrote: > > Do you want me to remove the _() calls (if that is the decision)? > > I have removed those and committed the changes and the updated > template.po file. In addition to the _() removal I made few > cosmetic tweaks: > > 1. Remove 'import string' and change 'string.strip(data)' > to 'data.strip()'. > 2. Remove importing of SubstKeywords, Date, and DateHandler > modules, seemingly unused. > 3. Tweaked generic Widget's help and valid_text, to be more > suitable for CLI help. Most likely this will never be > seen by the user, but as long as there are some placeholders > I figured it's better to have them fit their role. > > Let me know if any of those changes was in error and I'll fix it. Sounds great. > I also have a question for you: was it your intention to mark > the plugin as Unsupported? The idea of unsupported reports was > that this category contains reports that may or may not be > working, and which we do not care much about. Sort of contributed > reports. We would ignore any bug reports on the unsupported > reports and just tell the user that those are not what we > suggest to use. I just copied the values from another "unsupported" report. Please set all of those settings to appropriate values. > As long as you're willing to cooperate on developing/fixing > this report, I see no reason as marking is unsupported. Even > if it's not bullet-proof stable (status can be used for that), > we may ship it as supported and keep working on it. It will be supported, so that sounds correct. > Finally, while we're at it, would you like to get write > access to the CVS so that you don't need a middleman to > commit the changes each time? If so, let me know your > sourceforge user name and I'll add you to the devel list. Sounds like a practical idea :) Let me at it! I suspect I should now take an oath to do no harm, and pledge my allegiance to gramps :) -Doug > Let me know what you think, > Alex > -- Douglas S. Blank Computer Science Assistant Professor Bryn Mawr College (610)526-6501 http://cs.brynmawr.edu/~dblank |
From: Don A. <don...@co...> - 2006-02-24 20:28:43
|
Douglas S. Blank wrote: > On Thu, 2006-02-23 at 11:35 -0800, Alex Roitman wrote: > >>Finally, while we're at it, would you like to get write >>access to the CVS so that you don't need a middleman to >>commit the changes each time? If so, let me know your >>sourceforge user name and I'll add you to the devel list. > > > Sounds like a practical idea :) Let me at it! I suspect I should now > take an oath to do no harm, and pledge my allegiance to gramps :) > > -Doug > > Of course, you realize that this will get your name added to the bug tracker... :-) Don |
From: Alex R. <sh...@gr...> - 2006-02-24 20:56:30
|
On Fri, 2006-02-24 at 15:24 -0500, Douglas S. Blank wrote: > I just copied the values from another "unsupported" report. Please set > all of those settings to appropriate values. >=20 > > As long as you're willing to cooperate on developing/fixing > > this report, I see no reason as marking is unsupported. Even > > if it's not bullet-proof stable (status can be used for that), > > we may ship it as supported and keep working on it. >=20 > It will be supported, so that sounds correct. Done. > > Finally, while we're at it, would you like to get write > > access to the CVS so that you don't need a middleman to > > commit the changes each time? If so, let me know your > > sourceforge user name and I'll add you to the devel list. >=20 > Sounds like a practical idea :) Let me at it! I suspect I should now > take an oath to do no harm, and pledge my allegiance to gramps :) Just giving me your sf.net user name would be enough :-) Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Julio S. <jul...@gm...> - 2006-02-26 08:35:06
|
2006/2/19, db...@br... <db...@br...>: > Thanks for testing. The calendar code does scale the calendar to fit > within the page width and height. The font-scaling is an interesting idea= , > but I'd like to solve these other basic problems first. (Of course, you > can change the font size in options). And, I hope that we can have a > dynamic view of all reports so that you see changes on-the-fly. That woul= d > make it easy for the human to set the right font. I have been testing this and I found some difficulties. The main problem is that names overflow their boxes. Our names are long, much longer than you are used to. So boxes overflow and the result is unreadable. I don't think that font scaling alone will do. This is a not a new problem, it is general for us and happens on pedigrees and other graphs as well. For GraphViz I have my own kludge, but I think we should have something more solid. For instance, phpGedView either flows text where it can or abbreviates it down to initials with heuristics (that happen to be wrong for us, but that's besides the point and, at least, they try) where not feasible. On a related topic, not all docgen plugins seem to manage font sizes correctly. ODT, for instance, does not obey font size settings. PDF output seems to, but I am not sure. Custom styles lose descriptions, i.e. if you create a custom style and save it, it will no longer describe what each style element is for.=20 Maybe it fails before saving too, but I did not check. Last, is the alive people restriction supposed to work? I chose 'only living people' and I get anniversaries for people with over 300 years and such. Nice idea, anyway, I hope I can use it soon. Best regards, Julio |
From: <db...@br...> - 2006-02-27 01:13:27
|
> 2006/2/19, db...@br... <db...@br...>: > >> Thanks for testing. The calendar code does scale the calendar to fit >> within the page width and height. The font-scaling is an interesting >> idea, >> but I'd like to solve these other basic problems first. (Of course, yo= u >> can change the font size in options). And, I hope that we can have a >> dynamic view of all reports so that you see changes on-the-fly. That >> would >> make it easy for the human to set the right font. > > I have been testing this and I found some difficulties. The main > problem is that names overflow their boxes. Our names are long, much > longer than you are used to. So boxes overflow and the result is > unreadable. I don't think that font scaling alone will do. This is a > not a new problem, it is general for us and happens on pedigrees and > other graphs as well. For GraphViz I have my own kludge, but I think > we should have something more solid. For instance, phpGedView either > flows text where it can or abbreviates it down to initials with > heuristics (that happen to be wrong for us, but that's besides the > point and, at least, they try) where not feasible. Julio, Yes, you are right. What is needed is a fixed box size that will wrap the text, and make the text fill from the bottom up. Is there such a docgen abstraction? In addition, Some names may still be too long, and may need to be broken (hyphenated) or maybe just truncated. Also, there needs to b= e a limit to how much text is allowed on any one day. The overflow text could appear at the end of the month, or on a second page. Another related problem is the page width/height. Currently, the default makes very wide margins (1 inch) although my printer allows smaller. If that were smaller, it would allow the calendar boxes to be larger. I am making a list of TODO's for the calendar, and I have added the box size /wrapping text to it (along with the "Use Wedding Name if available"). I can see that this is a non-trivial project to make complet= e and will take a little while to get just right. The other items below I think are docgen issues unless I'm doing somethin= g wrong. Can you provide more feedback if you have these problems across al= l reports, or just the calendar? Thanks! -Doug > On a related topic, not all docgen plugins seem to manage font sizes > correctly. ODT, for instance, does not obey font size settings. PDF > output seems to, but I am not sure. > > Custom styles lose descriptions, i.e. if you create a custom style and > save it, it will no longer describe what each style element is for. > Maybe it fails before saving too, but I did not check. > > Last, is the alive people restriction supposed to work? I chose 'only > living people' and I get anniversaries for people with over 300 years > and such. > > Nice idea, anyway, I hope I can use it soon. > > Best regards, > > Julio > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd____________________________________= ___________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Eero T. <ee...@us...> - 2006-02-27 20:38:55
|
Hi, > Yes, you are right. What is needed is a fixed box size that will wrap the > text, and make the text fill from the bottom up. Is there such a docgen > abstraction? In addition, Some names may still be too long, and may need > to be broken (hyphenated) or maybe just truncated. Hyphenation is language specific, just truncate the text. (Pango can already do truncation from beginning, middle or end of text, but that works only for Gtk widgets unfortunately, not Gramps report output :-)) - Eero |