掲示板 Forums - PDFs need work

I'm finding out there are issues with PDFs and it seems the feature at times is broken. I'm not sure how long this is going on, but it seems in some cases I have some post-production work to do when I shouldn't have to do so, and there are some weird, mixed results.

Tinker view ends up as a solution for one problem, but doesn't help the others. It helps on one case with say, the 1st grade/N5 kanji list of 80 kanji, which I can use for 1 kanji per page. But it doesn't do much for me for longer lists, which also sometimes breaks the function, to which I have to change the view in order to print a PDF based on the displayed page. In addition to that, I have to consolidate them all in one list if I want to have them in one document.

The multiple kanji sheet has quite some limitations. It only goes up to 10 pages, nothing more. Size of the sheet also matters, which gives weird results. B5 will show up to 5 kanji per page. Any other size is 7 - which is weird because the description says the sheet should display up to 6 kanji? The page limit hampers the number of kanji anyway, which on top of that, the last page only shows 1 kanji.

Overall, the PDF function doesn't do what I would expect it to do, and the post-production I have to do is extra work to get what I want if I want to have the whole list. It's one thing to piecemeal the material for some practice, but if I intend on having everything I have, I shouldn't have to be doing more just for such a simple feature.

It is the weekend, so i do not have time to look into this yet, but if either of you can provide very specific steps for a few of the error cases, it'll make it much easier for me to look at them later on next week.

1. The bug I found:

Building a worksheet (PDF) requires this HTML form to be populated correctly - id = thelist_form. More specifically, the value field of the input element with id = idlist needs to be populated with the IDs of the kanji currently on display.

This only works with one page, which is why PDFs are limited in the number of kanji they can have. This is by design.

The value field gets populated when you "load" a list. This works fine in schedules and community lists, but when you load kanji from Advanced Search, the field stays empty. Naturally, when you click the Download button, nothing happens.

This is very unlikely to be related to what OP is describing as it's a client-side problem that occurs before the Ajax request.

2. What OP is (likely) describing:

An example with multi-kanji on A4:

The maximum number of kanji that get printed is 50 in any view except Tinker mode (a full page). 7 kanji per page, 1 kanji on the last page (8 pages in total).

The maximum number of kanji that get printed in Tinker mode is 64 (not the full page). 7 kanji per page, 1 kanji on the last page (10 pages in total).

An example with multi-kanji on B5:

The maximum number of kanji that get printed is 46 in any view (missing the last 4). 5 kanji per page, 1 kanji on the last page (10 pages in total).

Single-kanji sheets seem to get generated fine (A4 and B5) at 50 pages. Basically a full page.

When I try to generate a single-kanji sheet in Tinker mode it gives me an error. The backend is likely not set up to handle more than 50. To me this makes sense. There's a limit to what you can handle before you start encountering problems.

Multi-kanji sheets can definitely handle more load though. Backend should be able to handle at least 4x the amount of kanji no issue.

PS: I'm simply describing issues, not demanding changes :)

I get 10 pages. That's 9 pages of 7 kanji and one page of 1 kanji. 9*7+1 = 64

Also, can you do me a favour and check if you can generate PDFs from Advanced Search so I know it's not just something on my end?

Edit: Here's some screenshots

And this lines up with the 64th kanji in Tinker mode:

Edit: Give me sec to check what I wrote. I got a bit tangled with all of those numbers XD

Yeah, the first one was meant to be 7*7+1 = 50, my bad.

Edit: Oh, wait... what I wrote checks out, but I never specified the page difference. It's 8 pages for normal view and 10 pages for Tinker. 7*7+1 and 9*7+1. I can see why what I wrote was confusing. I'll fix it.

You can go to Advanced Search and see if you can generate PDFs. If you have same problem, the "Download" button won't do anything.

Testing the other issues on a phone is probably going to be too annoying, so I wouldn't bother. You can if you want to of course. It's the same thing, just from a list or schedule.

Yeah, so it's just bugged for everyone. The IDs don't get generated, so the function that makes the Ajax request "fails". I'm 99% sure it's that, since if I add some IDs manually it works.

Edit: Thank you for checking :)

Interesting. From your list right? - "By radical > 195 - fish radical 魚（うお）". I get 6 pages (7*5+1) = 36 kanji. This is for multi-kanji. For single-kanji I get 13.

The form looks to be sending 109 IDs, so the problem is server-side. As you said, probably some lack of data.

Edit: To clarify, this is all on A4.

No, this is consistent. What's inconsistent is how it's produced. I know that a B5 size is 5 kanji per sheet. Everything else is 7. Changing views, Tinker gives you a max of 10 pages, everything else is 8. So, depending on either of these combinations, the most you can get is 64 because the last page craps out to 1 kanji. One would think that changing to the 50 kanji view would at least get you 50, but somehow instead the best you can get is 46.

What an odd limit.

Community lists. I'm not using Advanced Search.

• I'd pick out a list.
• Choose a view.
• Hit the PDF button and choose the sheet size.

That is it.

All other PDF parameters are inconsequential to the matter.

This is why I've said this isn't complicated. There's only 2 different style sheets and anything tied to that is the view and sheet dimensions to control. There is literally nothing else to do with it. Involving Advanced Search is only another thing on top of that.