Introduction
Creative teams often need to review large images and design assets without installing the original authoring software on every workstation. Doconut is a .NET document viewer SDK that applications can use to display supported documents and images in the browser. Its current feature list includes TIFF, SVG, PSD, PNG, JPEG, BMP, and GIF alongside PDF, Office, CAD, email, and other business formats.
1. The Real‑World Challenge: Previewing Complex Image Formats in a .NET Web Portal
Design studios often spin up internal portals where clients, art directors, and junior designers can upload drafts, compare revisions, and sign off on final assets. Sounds simple, right? In practice three technical hurdles keep popping up:
| Pain point | Why it matters for designers & photographers |
|---|---|
| Plugin dependency – Traditional viewers rely on Adobe Flash, ActiveX, or third‑party browser extensions. | Users waste time installing or updating plugins, and corporate IT blocks many of them for security. |
| Preview fidelity – A poorly configured preview pipeline can change color, gradients, transparency, or fine detail. | Color-critical work needs representative testing before reviewers rely on a browser preview. |
| Large or complex assets – TIFF and PSD files can stress processing, memory, and zoom behavior. | Teams should test realistic files and infrastructure instead of assuming a universal size or performance limit. |
These problems get even messier in ASP.NET Core or MVC portals where the backend already handles authentication, storage, and versioning. Adding a separate viewer stack can introduce extra licences, maintenance, and security review.
2. Confirm the Formats and Capabilities You Need
Do not rely on a generic promise that every professional image format behaves the same way. The official Doconut feature page currently lists TIFF/TIF, SVG, PSD, PNG, JPEG, BMP, and GIF among its supported categories.
Test the exact files used by the organization, including large dimensions, transparency, embedded fonts, multiple pages, and damaged files. If a required format is not listed, confirm support with Doconut before promising it to users.
3. Step‑By‑Step: Embedding Doconut’s Advanced Image Viewer in a .NET Portal
Below is a practical walkthrough that a development team can follow to give designers an integrated preview experience. The example assumes an ASP.NET Core MVC project, but the same ideas work in WebForms, Razor Pages, React, or Angular front‑ends.
3.1. Add the Doconut Viewer Library
Use the current package and examples from the official download page. Record the selected version and verify compatibility with the target .NET runtime.
3.2. Set Up a Secure Upload Endpoint
Protect document access with the application's authentication and authorization model. Define storage, upload validation, retention, cleanup, and HTTPS behavior as explicit application responsibilities.
3.3. Build the Upload Form (Designers’ UI)
Create an HTML form for the file categories confirmed by current documentation and testing. The accept attribute can improve the user experience, but the server must still validate size and content.
3.4. Handle the Upload on the Server
When the form is submitted, validate and store the file outside publicly served directories. Resolve it for viewing only after server-side authorization succeeds.
3.5. Render the Viewer on the Preview Page
Initialize the viewer using the documentation supplied with the installed SDK version. Do not expose physical paths, storage credentials, or unrestricted file URLs. Confirm navigation, printing, annotations, and format-specific behavior before describing them as available.
3.6. Tailor the Toolbar for a Design‑Focused UI
Design the surrounding portal around the review task. Use only toolbar and UI customization points documented for the installed version, and remember that hiding a control is not a substitute for server-side authorization.
4. From Upload to Approval: The End‑to‑End Designer Workflow
The following workflow shows where an embedded viewer can support review while the original authoring tools remain responsible for editing.
4.1. Capture & Export
A photographer prepares a supported review asset such as TIFF, PNG, or JPEG while retaining the original source in the appropriate asset-management system.
4.2. Upload to the Review Portal
The photographer uploads the asset through an HTTPS endpoint. The application validates it, stores it according to organizational policy, and authorizes access to the review record.
4.3. Present and Validate the Preview
The application presents the supported asset through Doconut. Reviewers use the capabilities confirmed for the installed version and compare colour-critical output with the original in their controlled test process.
4.4. Layer Interaction for Supported Formats
For SVG or PSD workflows, test representative assets and confirm which inspection features are available. Do not assume layer interaction or vector fidelity without verification.
4.5. Collaboration & Feedback
The host application can place its own comments, approval controls, and version history beside the viewer. If the workflow needs annotations or navigation to a marked area, confirm those capabilities with the installed Doconut version. Audit logging remains an application responsibility.
4.6. Control Export and Print
Once the asset is approved, the application records the decision and handles any print, export, retention, or deletion step according to its documented policy.
This keeps review inside the portal while leaving editing and final production checks to the appropriate professional tools.
5. Extending the Viewer to Other Creative Scenarios (Briefly)
While we’ve zeroed in on graphic designers and photographers, Doconut’s engine shines elsewhere, too:
- Architects & engineers can preview supported DWG, DXF, and DGN files inside a project portal.
- Marketing teams preview PDFs, PPTX, and EPUBs alongside images, unifying the review process.
- Students in visual‑arts courses can upload and inspect assignments without needing pricey software licences.
These side uses show how a single viewer component can serve an entire enterprise, but the deep dive stays focused on the design workflow we just walked through.
Key Takeaways
- Browser viewing reduces the need for reviewers to install the original desktop authoring software.
- The application controls HTTPS, authorization, storage protection, retention, and cleanup.
- Colour-critical fidelity and format-specific tools must be tested with representative assets.
- Use the package and integration API documented for the installed Doconut version.
- Confirm documented toolbar and UI options for the installed version before designing role-specific controls.
- Storage protection, retention, cleanup, and compliance remain responsibilities of the complete application architecture.
Frequently Asked Questions
Q: What if my workflow requires a format that is not on the current feature page? A: Confirm support with Doconut and test representative files before committing to that workflow.
Ready to Empower Your Creative Team?
Review the current Doconut Viewer and test it with representative creative assets before committing to a production workflow.