Description
Comparing the README's own documented pages/ folder structure and
"Available endpoints" list against the actual routes registered in
App.jsx, several tool pages exist in the live code but are missing
from both the README's file tree and its backend endpoint list:
- PdfProtect (route: /pdf-protect)
- PdfUnlock (route: /pdf-unlock)
- PdfMetadata (route: /pdf-metadata)
- PdfToText (route: /pdf-to-text)
- PdfInfo (route: /pdf-info)
- PdfPageNumber (route: /pdf-page-number)
- UrlToQr (route: /url-to-qr)
- BlurImage (route: /image-blur)
App.jsx lazy-imports and routes to all of these:
jsx const PdfProtect = lazy(() => import("./pages/PdfProtect")); const PdfUnlock = lazy(() => import("./pages/PdfUnlock")); const PdfMetadata = lazy(() => import("./pages/PdfMetadata")); const PdfToText = lazy(() => import("./pages/PdfToText")); const PdfInfo = lazy(() => import("./pages/PdfInfo")); const PdfPageNumber = lazy(() => import("./pages/PdfPageNumber")); const UrlToQr = lazy(() => import("./pages/UrlToQr")); const BlurImage = lazy(() => import("./pages/BlurImage"));
But the README's "Folder Descriptions" section, which lists every page
component individually, doesn't mention any of these eight. The
"Available endpoints" section similarly lists no backend route for
PDF protect/unlock/metadata/to-text/info/page-numbering, QR generation,
or image blur — and the blueprints/ folder listing in the README
doesn't show a matching Python module for any of them either
(e.g. no pdf_sign.py, pdf_protect.py, qr.py, blur.py, etc.).
Why this matters
Three possibilities, and it's not clear from the README which applies:
- These tools run entirely client-side (no backend call needed — e.g.
QR generation or image blur via Canvas could be done in-browser) and
the README simply hasn't been updated to say so.
- The backend endpoints exist but were never documented in the README.
- These are work-in-progress/stub pages that don't fully work yet.
Any of these is fine, but as written the README actively misleads new
contributors (including GSSoC participants) about what's implemented
and where — someone could spend time building a backend endpoint for
something that's already client-side, or vice versa.
Suggested Fix
A maintainer confirms which of the three buckets each tool falls into,
then the README's pages list and endpoints list get updated to match
the actual current App.jsx. Happy to do the documentation update myself
once the implementation status is confirmed.
Confidence
High on the documentation mismatch itself (directly comparable from the
pasted App.jsx vs. the pasted README). Low on whether any of the eight
tools are actually broken — that depends on code I haven't seen.
Description
Comparing the README's own documented
pages/folder structure and"Available endpoints" list against the actual routes registered in
App.jsx, several tool pages exist in the live code but are missingfrom both the README's file tree and its backend endpoint list:
App.jsx lazy-imports and routes to all of these:
jsx const PdfProtect = lazy(() => import("./pages/PdfProtect")); const PdfUnlock = lazy(() => import("./pages/PdfUnlock")); const PdfMetadata = lazy(() => import("./pages/PdfMetadata")); const PdfToText = lazy(() => import("./pages/PdfToText")); const PdfInfo = lazy(() => import("./pages/PdfInfo")); const PdfPageNumber = lazy(() => import("./pages/PdfPageNumber")); const UrlToQr = lazy(() => import("./pages/UrlToQr")); const BlurImage = lazy(() => import("./pages/BlurImage")); But the README's "Folder Descriptions" section, which lists every page
component individually, doesn't mention any of these eight. The
"Available endpoints" section similarly lists no backend route for
PDF protect/unlock/metadata/to-text/info/page-numbering, QR generation,
or image blur — and the
blueprints/folder listing in the READMEdoesn't show a matching Python module for any of them either
(e.g. no
pdf_sign.py,pdf_protect.py,qr.py,blur.py, etc.).Why this matters
Three possibilities, and it's not clear from the README which applies:
QR generation or image blur via Canvas could be done in-browser) and
the README simply hasn't been updated to say so.
Any of these is fine, but as written the README actively misleads new
contributors (including GSSoC participants) about what's implemented
and where — someone could spend time building a backend endpoint for
something that's already client-side, or vice versa.
Suggested Fix
A maintainer confirms which of the three buckets each tool falls into,
then the README's pages list and endpoints list get updated to match
the actual current App.jsx. Happy to do the documentation update myself
once the implementation status is confirmed.
Confidence
High on the documentation mismatch itself (directly comparable from the
pasted App.jsx vs. the pasted README). Low on whether any of the eight
tools are actually broken — that depends on code I haven't seen.