On Monday 27 December 2010 04:09:46 Prasenjit Kapat wrote:
> Hi,
>
> On Sun, Dec 26, 2010 at 7:57 PM, Stefan Rödiger <stefan_roedi...@gmx.de>
wrote:
> > On Sunday 26 December 2010 21:06:34 Thomas Friedrichsmeier wrote:
> >> Hi!
> >>
> >> I'll take another look tomorrow or the day after that. Some comments:
> >>
> >> On Sunday 26 December 2010, Stefan Rödiger wrote:
> >> > 0) Check for any missing authors guideline. From what I can see we are
> >> > conform the the requirements.
>
> I think we are good. I haven't checked the bib file, though.
This would be a good.
>
> >> > 1) I would like to ask everybody which final paragraph of the
> >> > background.tex and which of section "Help system" you prefer (look for
> >> > the %)?
> >> > you prefer.
> >>
> >> I like the style of the non-commented version, but it's not accurate:
> >> The example session come after the GUI elements, not after the
> >> technical details. And of course it's the technical details, which will
> >> be compared, where appropriate.
> >
> > Okay, I changed/corrected that and took the non-commented version
> > (regarding the background.tex).
>
> The latest version (r3327) reads fine.
Okay
>
> > I need a vote for the section "Help system" too.
>
> Well, to me the earlier version seems a bit disconnected. Let others vote
> ;)
granted, :)
>
> >> > 2) Please give me feedback which figure are not good readable for you.
>
> I think the figures are fine in terms of their content. But they don't
> seem "clear" especially the fonts.. I think nothing can be done to
> improve them either - all screen captures will result in this type of
> quality :(
>
There is a bit I can do. I did so for some figures. Basically it means to
adjust the resolution and not the size of image, which leads to at least a
better quality on a printout. ... But indeed this is not much.
> >> > 3) Check that we use consistent term etc. (for example it's always
> >> > "section" not
> >> > "Section", "Figure" not "Fig." or "figure"). Other examples are "help
> >> > page" vs. "help-page" or "``Submit button''" vs. "Submit button".
>
> Yes, one thing has been confusing me: when we refer to a menu item or
> a GUI button, our draft is using double quites (``...''). Is that OK?
> For example "``Submit'' button" vs "Submit button" or "``Help'' menu"
> vs. "Help menu"?
Matter of taste in my opinion. Keeping it without quotes means less trouble
and I can read it better. But let's stick with one. "``Help'' menu" would be
my favourite.
>
> >> > 4) If I get it right \proglang{} is only for languages (XML, HTML, R,
> >> > C++, Qt, ECMAScript, ...) not for programs like Red-R or RKWard (see
> >> > 5)).
> >>
> >> Yes, but it does not appear to be clear-cut. Citing from jss.dtx:
> >> % This should be used for typesetting the names of programming
> >> % languages, e.g., |\proglang{Java}|, |\proglang{C++}| or
> >> |\proglang{R}|. % This applies also to programmable environments which
> >> also have a GUI % like |\proglang{SAS}|, |\proglang{Stata}| or
> >> |\proglang{S-PLUS}|.
> >>
> >> Programmable environments could certainly be stretched to include KDE,
> >> but also Red-R, and RKWard. Still I guess it's best to restrict it as
> >> you suggest.
> >
> > Okay, we keep it without anything. We keep \proglang{KDE} but stick with
> > Red-R and RKWard.
> >
> >> > 5) Do you wish to emphasise words like RKWard, TDI?
> >>
> >> We certainly shouldn't emphasise all technical terms like TDI. We might
> >> emphasise RKWard (see above), but I'd leave it as is, for now. If the
> >> editors want that, it will be easy to revise.
> >
> > Same opinion here. I just had the impression that some co-authors prefer
> > it emphasised.
> >
> >> > 6) Does anybody see a need to add something to Conclusion and Outlook?
> >> > If so when do you plan to finish it?
> >>
> >> I don't plan to add anything.
> >
> > Okay. Same for me.
>
> I'll take a look at them tonight.
okay
Another point. We all consent to use AE not BE, right? I checked and all is
correct from what I saw.
>
> >> > Generally:
> >> > * 31.12 is the official deadline. I would like to sent it earlier (29.
> >> > or 30. in case the editors need something else).
> >>
> >> Yes. I propose to target the 29th, meaning the 28th will be the last day
> >> to make any changes. Of course if there is a good reason to add another
> >> day, we can still do that.
> >
> > Okay. Let's stick with it. Official target is the 28th with the 29th as
> > buffer.
> >
> >> Regards
> >> Thomas
> >
> > Regards
> > Stefan
> >
> > Side note: The weather is quite unpredictable and I have to use a surf
> > stick currently ... . In case you don't see a "I submitted" message from
> > me on the list (latest 30th evening) somebody else shouldn't hesitate to
> > submit. Who wants to be the "backup"? To make it clear I intend to
> > submit the paper as we discussed before (unless there is a unforeseeable
> > reason). I would just like to be on the safe side.
>
> If Thomas can, that'll be the best. If not, I can. We just have to
> send the pdf file via email, right?
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel
