Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exporting to PDF fails. #2

Open
cfcohen opened this issue Mar 25, 2021 · 0 comments
Open

Exporting to PDF fails. #2

cfcohen opened this issue Mar 25, 2021 · 0 comments

Comments

@cfcohen
Copy link
Owner

cfcohen commented Mar 25, 2021

When exporting a map to PDF, it fails with:

There was a problem exporting the map:
Object reference not set to an instance of an object.

No exception was generated, but removing the catch exception block yielded:

System.NullReferenceException: Object reference not set to an instance of an object
  at Trizbort.UI.Controls.Canvas.Draw (PdfSharp.Drawing.XGraphics graphics, System.Boolean finalRender, System.Single width, System.Single height) [0x000d2] in <b0f85e845ba74be19b81293379b46981>:0 
  at (wrapper remoting-invoke-with-check) Trizbort.UI.Controls.Canvas.Draw(PdfSharp.Drawing.XGraphics,bool,single,single)
  at Trizbort.UI.MainForm.savePDF (System.String fileName) [0x000c2] in <b0f85e845ba74be19b81293379b46981>:0 
  at Trizbort.UI.MainForm.FileExportPDFMenuItem_Click (System.Object sender, System.EventArgs e) [0x0004a] in <b0f85e845ba74be19b81293379b46981>:0 
  at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs e) [0x00019] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.ToolStripMenuItem.OnClick (System.EventArgs e) [0x00090] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.ToolStripMenuItem.HandleClick (System.Int32 mouse_clicks, System.EventArgs e) [0x00000] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs e, System.Windows.Forms.ToolStripItemEventType met) [0x00054] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem.FireEvent(System.EventArgs,System.Windows.Forms.ToolStripItemEventType)
  at System.Windows.Forms.ToolStrip.OnMouseUp (System.Windows.Forms.MouseEventArgs mea) [0x00048] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.ToolStripDropDown.OnMouseUp (System.Windows.Forms.MouseEventArgs mea) [0x00000] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message& m) [0x00078] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x001b4] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message& m) [0x00000] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.ToolStrip.WndProc (System.Windows.Forms.Message& m) [0x00000] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.ToolStripDropDown.WndProc (System.Windows.Forms.Message& m) [0x00017] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x0000b] in <6d635ac3dc1c4424ad385ded79f1e868>:0 
  at System.Windows.Forms.NativeWindow.WndProc (System.IntPtr hWnd, System.Windows.Forms.Msg msg, System.IntPtr wParam, System.IntPtr lParam) [0x00085] in <6d635ac3dc1c4424ad385ded79f1e868>:0
cfcohen added a commit that referenced this issue Mar 27, 2021
This commit also displays _very_ poorly in Mono on Linux, but I've
included it to ensure that the problem in the previous commit is not
related to the encoding of the source code file.  For me, both commits
produce essentially identical results (correct on console, nothing on
the check boxes inside the application).
cfcohen added a commit that referenced this issue Mar 27, 2021
This commit is an improvement on Linux if you don't have the Wingdings
font (which is provavly all Linux users by default).  Without the
Wingdings font, you get random characters that don't communicate the
purpose of the checkbox widgets at all.  With this commit, the north,
south, east and west arrows render reasonably and the other five
characters render as "missing character squares" which in my opinion
makes it a little more obvious what was intended.

Unfortunately, despite being only a few characters away from each
other in unicode, on my system the cardinal directions are "normal
width" unicode characters rendered at with a lighter weight, while the
five missing characters are extra wide, and substantially heavier in
their rendering.  So they're definitely not "harmonious".

If it works (and looks good) in Windows, I think this solution should
be considered temporarily since it's an improvement on Linux, and it
might get fixed before the commits #1 or #2, which is what should
really be done long term. If this doesn't look good on Windows, we
should revert to the original source code, and advise non-Windows
users to somehow obtain and install the Wingdings font.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant