December's Most Wanted list

[denise]

Sometimes people look at the list of bugs we have open and wonder which ones would most benefit Dreamwidth, or wonder which ones to start on, or wonder what's most-requested, etc etc etc. I decided that I'd start making a monthly list of the bugs I most want resolved from a business standpoint and posting it, for people to pick from if they find something they find suitable.

This is just my personal list -- Mark may have his own! -- and I've tried to keep it a mixture of little and big.



1. Bug 2203: Paid time gift promotion (claimed by mark)

2. Bug 2092: allow premium-paid users to buy regular paid time within window of expiration

3. Bug 216: Implement renames (claimed by afuna)

4. Bug 135: Gift certificate/credits system

5. Bug 225: Create a single-user backup tool

6. Bug 177: implement admin/sendmail.bml as dw-free

7. Bug 76: Main/alternate account system

8. Bug 32: Export journal as .pdf

9. Bug 1985: Update FCKeditor to version 2.6.5

10. Bug 1433: Sort alpha by keyword on allpics/editpics pages

11. Bug 1230: Replace custom mood theme editor (Claimed by wyntarvox!)

12. Bug 395: Increase syn feed max size (Claimed by me)

13. Bug 31: Expand all comments on page

14. Bug 1239: HTTPS browsing mode

15. Bug 1408: fix up custom domain aliasing on entry pages

16. Bug 34: Index/archive pages, for simple one-click website building

17. Bug 2020: snooze button for specific people on your reading list

18. Bug 478: IM-to-DW chat log formatter

19. Bug 477: Icon table generator (Gonna give this one a try myself.)

20. Bug 500: Importer should be aware of edits if run again

Comments

[libitina]

Bug 2020 - Oooo... shiny!

Bug 500 - yes, please. :)

[ciaan]

Oh, custom mood theme, I have tried multiple times to set one up and it has randomly failed every time for no reason I can figure out. :(

[vlion]

I think Bug 32 would be nice.

I could work on a DW->Latex interface, which would be able to be put into a pdf generator

[denise]

(You got an out-of-thread response here, FYI.)

[vlion]

thanks!

[peoppenheimer]

Denise, it is very helpful to have this list.

Vlion, what would be the advantage, for purposes of pdf generation, of going via LaTeX, rather than via the underlying rendering engine of one of the browsers? Of course, going the LaTeX route would be lots of fun, but the information for the refined typesetting capabilities of LaTeX isn't in the html+css, so I can't see why the full capabilities of LaTeX would be needed. When time permits, I can try to find out something about the way the pdf for the Friends of the SEP Society is generated. We offer nifty custom pdf to people to join the Friends. I have not been at all involved in that effort—I just use the pdf renderer as part of the quality assurance process for an entry before sending it back to authors for final proof reading—so I know nothing about our code. Whether I could share any of the code, I don't know. The encyclopedia contents are open access, but the Friends are part of our fund raising, and it may be that we will want to protect the code we use for that—the question hasn't come up before now, and I need to discuss it with the others. In any case, this is something I might be able to help with, but probably not until after mid-January, when the last of the house guests will leave. I would certainly be interested in continuing the discussion about possible approaches, however.

[foxfirefey]

The full capabilities of LaTeX aren't needed, but LaTeX does provide a good tool that translates the templates into PDFs. It's the backend of LJBook. It works on Unix based systems like we have, uses open source components, and is easily automateable.

I don't know about other systems, however, so it might be an instance of having a hammer I know about so the problem looks like a nail, when really it might be a screw needing a screwdriver.

[vlion]

The primary advantage is that Latex -> PDF tools exist, freely and
reliably; it's also well-known and reams of documentation exist. A
subsidiary advantage is that Latex would be translatable into other
formats, if so needed 'down the road'. Another subsidiary advantage is
that typesetting is largely managed by Other People Whose Code We
Don't Have To Debug.

There *are* other tools to take text & images and convert to PDF. I
would be surprised, however, if they are are as well known, debugged
or as good in licensing for DW.

Let me toss some thoughts down in a more formal fashion about how this
would have to look.

I would expect the architecture to follow this model in some fashion.

Journal DB -> Reformatter -> PDF Generator

The reformatter will be putting the journal into a paperable form
suitable for the PDF generator to receive it. Possibly the
reformatter will manage some of the filtering options as well. A
filter block might be suitable further up the pipe.

The PDF generator will come in one of several flavors; roll-your-own,
use external library(e.g., CPAN's PDF exporters), use latexy tool that
adds a new step in the process, possibly allowing output in non-pdf
formats as well.

Suppose we have some kind of filter block and use latex:

DB -> Filter -> Reformatter -> Latex Generator-> Latex/PDF generator.

The filter will be managing queries and ensuring that only the 'right'
data comes through.

The reformatter will be doing such things as large comment thread
management, image management, etc.

The latex generator will be reading the "ready-to-go" data and
outputting a Latex text document that has the content.

Of course, latex itself can produce final output in pdf, html,
man(prob-ably not needed), and I expect it to continue being able to
output in whatever formats come onto the scene and are widely
accepted.

Yet, I see some basic challenges with my idea:

1. Latex. It's mind-blowingly annoying at times and requires Yet
Another set of highly specialized knowledge.

2. Latex. It's not the most general thing on the market without
modifications. What happens if we get a group of non-English users?
Document handling for them has to come into being then.

3. Latex. It's a sledgehammer. Is the problem a screw? It'll still Jam
The Widget Into The Thingie, but maybe it's not quite the right kind
of jamming that a screwdriver will provide.

[superluminal]

(La)TeX today has quite good support for non-Latin writing systems and other aspects of i18n, especially if you use the XeTeX engine for native Unicode and Opentype support.

[vlion]

Aaaah. I don't use non-Latin fonts, so I was ignorant. Thank you!

[vlion]

Oh, as a side comment.

If the journal could be globbed together into an one giant print-styled html page, then perhaps a Javascript library could be used to create the PDF from the html or a pdf printer driver could be used and 'printed' to the pdf. (not that the print quality there is that great typically, IMO).

edit: There exists a javascript library, fairly new, that allows pdf generation with pure JS.

[the_shoshanna]

Regarding bug 2203, the paid time promotion: if a seed account holder bought someone a paid/premium time gift, could they gift the two months, which wouldn't do them any good, to a third person? *cough*Hypothetically*cough*.

Hm, if this were put in place, though, I'd want the notification of the two-month gift *not* to make it obvious that the time was a bonus on the purchase of more time. I mean, it's nice to hear that someone gave you a present, but not so nice to be told, "Hi, someone gave you some paid time, but NOT AS MUCH AS THEY GAVE SOMEONE ELSE, NYAH." Rather than have that happen, I'd toss the extra two months into the gift-a-random-user pool, where a recipient won't have their feelings hurt (I hope) because they know it's completely random. Maybe that's the better policy across the board.

Or, you know, there aren't that many seed accounts. The two-month bonus could just evaporate; we're not owed it.

[denise]

I think, given the hassle, it should just not come into play for seed accounts.

[the_shoshanna]

Fair enough!

[msilverstar]

Backup and/or export is my #1 by far. I would like an HTML option because I hate pdf.

And expand all entries.

Rename would be really nice.