|
678 | Feature Request | HiTi family | Figure out what the 'p' 'm' and 'r' quality identifier ... | Researching | 2023-12-15 |
Task Description
h == Normal Quality q == High Quality p/m/r == ??? There's also the LUT files with H/M/T quality codes. |
|
665 | Feature Request | HiTi family | Supprt "sheet" models like the P310 and P320 series. | Waiting on Customer | 2023-06-12 |
Task Description
I have a P461 now, and it's different enough to be annoying. Turns out there are three major families, "roll type", "sheet type" and "card type" and the commands aren't all the same. !%!%# |
|
657 | Feature Request | Mitsubishi CP-Dxx family | Query and set vertical calibration | Assigned | 2021-05-16 |
Task Description
A user has a EK305 that cuts about 1mm off. Mitsubshi's service manuals reference a "Service Tool" that can adjust this calibration (and other things) |
|
585 | Feature Request | Zebra printers | Add support for Zebra ID card printers. | New | 2020-03-17 |
Task Description
I have a P120i that is in perfect working order. |
|
569 | Feature Request | Mitsubishi CP9xxx family | Figure out image processing algorithms for CP-98xx fami... | Requires testing | 2023-11-25 |
Task Description
They're an older-generation of the D70 family's. Data tables are unfortunately embedded inside the drivers, which makes this a lot more challenging. Sigh.
(If nothing else, simply obtaining the RGB->YMC conversion/gamma tables would make the printers immediately useful..) |
|
520 | Feature Request | Sony UP-D printers | Investigate Sony UP-CR20L aka DNP SL-20 | Requires testing | 2020-11-10 |
Task Description
Sony sold their printer line to DNP, which rebranded these two models. Investigate their Spool format, and find out if they need an intelligent backend. |
|
500 | TODO | Other printers | Add support for the Shinko S8145 | Waiting on Customer | 2023-10-01 |
Task Description
The T1/S8145 is a fancy "silver foil" thingey with two print heads. Won't happen until a user with one shows up. |
|
442 | Feature Request | User Interface | UI Enhancements | Assigned | 2013-01-08 |
Task Description
This will be a placeholder for the various ideas I have for reworking parts or all of PO's UI. Ideas that are fleshed out can be moved into their own tickets for actual implementation. * AJAX-ish tabs on the photo page - instead of a separate page reload for each tab, load all tab info at once and let the UI manage paging. * Client-side sorting of all tabular data - eg folder/album listings * Dynamic client-side pagination of the slide view - "dump" all slides at once, and let client-side manage their pagination? - Probably can't sort this way though * Lightbox-esque view of photos - Intended for guest access, hiding details of photos. - Slideshow capabilities - Easy navigation (eg using left/right arrows) * Replace ad-hoc toolbars with more coherent ones * Replace hackish button/checkbox theming script with something saner. * Replace wz_tooltips and js_calendar with better integrated stuff. * Modal login/password form - pops up on top of current page - Can force current page to reload afterwards - What to do about 401/403 errors? * Replace all "confirmation" pages with modal dialogs. I'm leaning towards Query and jQueryUI for actual implementations. Initial implementation will probably require current themes to be taken out back and shot. |
|
89 | Feature Request | Backend / Core | allow advanced search on any database field | Assigned | 2008-04-22 |
Task Description
RE-do the advanced search so it's more useful -- allow any field to be searched, not just title, caption, etc etc... then build the query on the fly. This is going to be complicated, but necessary... |
|
11 | Feature Request | Backend / Core | Clean up database conventions | Assigned | 2008-10-03 |
Task Description
Most database results are being indexed by position in a fixed array, rather than by column name. This may be slightly faster, but is hell to program around, especially when there can be twenty fields being returned. * Convert all fetch_row() calls to fetch_assoc() Secondly, using prepared statements would make the code a lot cleaner and eliminate the need to escape strings being passed in to the database. Unfortunately, this may require PHP 5.1 to pull off, depending on the maturity of the postgres bindings for earlier versions. * Use prepared statements and SQL variables instead of inlined data. |
|
8 | Feature Request | Backend / Core | Better permission hierarchy | Assigned | 2008-09-18 |
Task Description
Right now there are three permissions -- public, private, and "protected", which equates to "public only to all of my clients" This is pretty lousy; I can certianly envision scenarios where you'd want a client to only see stuff that's specific to that client. To do this now, you have to create separate accounts and mark clients for those specific accounts. I'd like to see a more generic hierarchical user/group model. Only the photo owner can make changes to their images, but the permission model would break down as follows: Permissions would be granted on a per-group basis, and individual users can be members of various groups. "Guest" access would just be another group, and would default to assigned. A permission is inherited; so if "guest" is granted access to the top-level folder, they would be allowed to see everything below it unless a more restrictive permission was specified. This is sort of similar to unix permissions with the "sticky bit" turned on. This gets a little tricky when talking about folders vs albums, as a user may not be allowed to browse the folder, but the image could be included in a public album. When viewing the image from the folder perspective, it would be disallowed, but from the album perspective, it would be allowed. EDIT: see http://po.shaftnet.org/new_permission_model |